WO2011047901A1

WO2011047901A1 - Verfahren und vorrichtung zum testen eines systems mit zumindest einer mehrzahl von parallel ausführbaren softwareeinheiten

Info

Publication number: WO2011047901A1
Application number: PCT/EP2010/062148
Authority: WO
Inventors: Florian Mangold; Harald RÖLLE
Original assignee: Siemens Aktiengesellschaft
Priority date: 2009-10-21
Filing date: 2010-08-20
Publication date: 2011-04-28
Also published as: DE102009050161A1; US20120278660A1; US8972784B2

Abstract

Erfindungsgemäß wird eine programmierte Laufzeitdauer zumindest einer Softwareeinheit in eine einstellbare Laufzeitdauer geändert. Weiter wird ein Testmittel zum Validieren des Systems und zum Einstellen der zumindest einen einstellbaren Laufzeitdauer bereitgestellt. Ferner wird das System mittels des Testmittels getestet, wobei das Testen ein Variieren der zumindest einen einstellbaren Laufzeitdauer zur Detektion von Synchronisationsfehlern des Systems beinhaltet. Somit wird ein Test eines Systems mit Softwareeinheiten auf Synchronisationsfehler durch gezielte Änderung der Laufzeitdauern ermöglicht. Ein Blockschaltbild für eine entsprechende Vorrichtung, Ablaufdiagramme für entsprechende Verfahren und ein Computerprogramm-Produkt zur Durchführung eines solchen Verfahrens sind angegeben.

Description

Beschreibung

Verfahren und Vorrichtung zum Testen eines Systems mit zumindest einer Mehrzahl von parallel ausführbaren Softwareeinhei- ten

Die Erfindung betrifft ein Verfahren und eine Vorrichtung zum Testen eines Systems mit zumindest einer Mehrzahl von paral^¬ lel ausführbaren Softwareeinheiten.

Das technische Gebiet der Erfindung betrifft das Testen von asynchron arbeitenden Softwareeinheiten eines Systems, um Synchronisationsfehler bei der Synchronisation der asynchron arbeitenden Softwareeinheiten zu detektieren.

Im Sinne der vorliegenden Anmeldung bezieht sich der Begriff Synchronisationsfehler auf einen Softwarefehler, der durch fehlerhafte oder nicht ausreichende Synchronisation der Soft^¬ wareeinheiten des Systems verursacht ist.

Ein spezieller Fall eines Synchronisationsfehlers ist eine so genannte Race Condition. Eine Race Condition bezieht sich auf die Möglichkeit, dass ein Softwarefehler auftreten kann und nicht bei jeder Ausführung des Systems auftreten muss. Eine solche Race Condition kann beispielsweise durch nicht^¬ deterministische Seiteneffekte bei der Ausführung des Systems auftreten. Somit sind Race Conditions nicht-deterministische und ungewünschte Effekte, und damit Fehler, welche aufgrund von Parallelität im System auftreten können.

[10; S.75] präzisiert, formalisiert und erweitert den Begriff der Race Conditions. Demnach sind Race Conditions Fehler, welche in Programmen auftreten können und bewirken, dass solche ein nicht-deterministisches Verhalten zeigen.

Data Races hingegen sind Fehler in Programmen, bei denen auf gemeinsam genutzte Daten in einem kritischen Bereich zugegriffen und diese verändert werden. Der Oberbegriff "Races" wird in der vorliegenden Anmeldung sowohl für Race Conditions als auch für Data Races benutzt.

Der Einsatz asynchron arbeitender Softwareeinheiten zur Abarbeitung paralleler Anweisungsblöcke hat mehrere Gründe. Ein wichtiger Grund liegt in der Effizienzsteigerung durch eine verbesserte Auslastung des Systems, beispielsweise eines Rechnersystems. Während das Softwaresystem auf die Eingaben eines Benutzers warten muss, können während dieser Wartezeit andere Berechnungen, Datenzugriffe oder dergleichen durchge- führt werden. Bei einer sequenziellen Ausführung ist dies nicht möglich. Durch eine parallele Ausführung steht das ge^¬ samte Softwaresystem damit schneller wieder für eine neue Benutzerinteraktion bereit. Damit wirkt das System performan- ter, weil der Durchsatz erhöht wurde. Die Perspektive hier ist die Performanzsteigerung eines einzelnen Programms.

Ein weiterer Grund für den Einsatz von parallel und asynchron arbeitenden Softwareeinheiten liegt in der Verwendung von Multitasking-Systemen. Multitasking-Systeme werden unter an- derem zur verbesserten Benutzerinteraktion eingesetzt. Solche Multitasking-Systeme müssen auch softwaretechnisch entspre^¬ chend auf Multitasking, also auf eine parallele Abarbeitung von zusammenhängenden Anweisungen oder Threads, konstruiert und implementiert werden. Die Perspektive hier ist die Per- formanzsteigerung eines Systems mit potenziell einer Mehrzahl gleichzeitig ausgeführter Programme.

Somit müssen zur Effizienzsteigerung und aufgrund neuer Rechnerarchitekturen Softwaresysteme hinsichtlich paralleler Ab- arbeitung konstruiert und implementiert werden. Beispielswei^¬ se Server-Systeme basieren in hohem Maße auf einer solchen Parallelität. Die daraus resultierenden vielgestaltigen parallelen Interaktionen in der Software sind für einen Menschen, insbesondere für einen Tester, nur schwer zu überbli- cken. Die einzelnen parallelen Abarbeitungslinien müssen zur Abarbeitung einer Aufgabe irgendwann, spätestens am Ende der Abarbeitung, wieder in korrekter Weise synchronisiert werden. Dies birgt ein enormes Fehlerpotenzial. Zusammenfassend ist ein asynchroner Betrieb von Softwareeinheiten oder Softwarekomponenten immer mehr gewünscht. Ausreichende Validierungsmethoden sind jedoch im Stand der Technik nicht vorhanden. Nach einer Untersuchung von Javacode durch David Hovemeyer und William Pugh [7] sind Synchronisations^¬ fehler eher die Regel als die Ausnahme.

Demnach ist es eine Aufgabe der vorliegenden Erfindung, eine verbesserte Möglichkeit zur Detektion von Synchronisations^¬ fehlern eines Systems mit einer Mehrzahl asynchron arbeitender Softwareeinheiten zu schaffen.

Erfindungsgemäß wird diese gestellte Aufgabe durch ein Ver- fahren mit den Merkmalen des Patentanspruchs 1 und durch eine Vorrichtung mit den Merkmalen des Patentanspruchs 14 gelöst.

Demgemäß wird ein Verfahren zum Testen eines Systems mit zu^¬ mindest einer Mehrzahl von parallel ausführbaren Softwareein- heiten vorgeschlagen, welche zur jeweiligen Ausführung eines Threads und zur Bereitstellung eines gemeinsamen Ergebnisses eingerichtet sind und welche eine jeweilige programmierte LaufZeitdauer der Ausführung haben. Das Verfahren hat folgende Schritte:

- Ändern der vorbestimmten LaufZeitdauer zumindest einer Softwareeinheit in eine einstellbare LaufZeitdauer ;

- Bereitstellen eines Testmittels zum Validieren des Systems und zum Einstellen der zumindest einen einstellbaren Laufzeitdauer; und

- Testen des Systems mittels des Testmittels, wobei das

Testen ein Variieren der zumindest einen einstellbaren Laufzeitdauer zur Detektion von Synchronisationsfehlern des Systems beinhaltet. Im Sinne der vorliegenden Anmeldung umfasst ein System eine Mehrzahl von parallel ausführbaren Softwareeinheiten, die insbesondere asynchron zueinander arbeiten. Dabei weist die jeweilige Softwareeinheit zumindest ein Programm und Daten auf .

Des Weiteren kann das System externe Faktoren, wie Hardwareeinheiten, ein Betriebssystem und optional andere Programme, umfassen. Insbesondere die Softwareeinheiten und die Hard^¬ wareeinheiten können miteinander agieren und sich gegenseitig beeinflussen .

Ein Programm besteht wiederum aus Modulen. Ein Modul ist ein strukturell zusammengehöriger Code. Ein Programmcode wird vorzugsweise in verschiedene Module gegliedert [12].

Die Softwareeinheiten, die Hardwareeinheiten sowie die Module können miteinander agieren und sich gegenseitig beeinflussen. Unter anderem können asynchrone Operationen hinzukommen. Zur Steuerung der zeitlichen Ausführung von nebenläufigen Arbeitslinien oder Threads ist vorzugsweise ein Scheduler oder Steuerprogramm vorgesehen. Dieser Scheduler muss selbst nicht-deterministisch sein und kann weiter unterbrechend (preemptiv) sein. Somit wird aus einem diskreten Code ein nicht-deterministisches und chaotisches und dadurch nur schwer beherrschbares System, das auf Korrektheit überprüft werden muss. Das Überprüfen auf Korrektheit des Systems mittels eines

Softwaretests wird hierbei als Validierung bezeichnet. Erfin^¬ dungsgemäß wird damit ein herkömmlicher Softwaretest mit ei^¬ nem empirischen Experiment hinsichtlich der Variation der LaufZeiteigenschaften kombiniert. Durch diese erfindungsgemä- ße Kombination können Sychronisationsfehler aufgefunden werden .

Dabei ist der Softwaretest im IEEE Standard 610 definiert als ein Prozess des Betreibens eines Systems oder einer Komponen- te unter definierten Bedingungen, wobei die Ergebnisse beobachtet und aufgenommen werden und eine Evaluierung mancher Aspekte des Systems oder Komponenten gemacht wird. Empirische Experimente in der Softwaretechnik werden in [8] beschrieben. Hierbei werden bestimmte Eigenschaften, vorliegend zumindest die LaufZeitdauer oder fakultativ weitere LaufZeiteigenschaften, verändert oder variiert, um analog zu einem Experiment aus den naturwissenschaftlichen Disziplinen Zusammenhänge aus dem beobachteten System abzuleiten. Das Verändern der LaufZeiteigenschaften von Softwareeinheiten wird durch die Nachbildung, beispielsweise die Virtualisie- rung und/oder die Emulierung, möglich. Da ein System aus un- terschiedlichsten Softwareeinheiten bestehen kann, können die LaufZeiteigenschaften unterschiedlichster Softwareeinheiten variiert und beobachtet werden.

Dabei umfasst das Variieren insbesondere ein mehrmaliges, aufeinanderfolgendes Einstellen der jeweiligen Laufzeiteigen- schaft .

Beim erfindungsgemäßen Testen werden einzelne Softwareeinheiten des Systems hinsichtlich ihrer LaufZeitdauer gezielt ver- ändert. Ein solches Verändern kann ein Verlängern (Prolongieren) , Verschieben (Retardieren) oder Verkürzen (simuliertes Optimieren) sein. Des Weiteren kann der StartZeitpunkt und/oder der Endzeitpunkt der Ausführung der Softwareeinheit verändert werden. Das Retardieren oder Prolongieren der je- weiligen Softwareeinheit wird von dem erfindungsgemäßen Testmittel durchgeführt. Das System selbst wird vorzugsweise durch eine virtuelle Maschine ausgeführt. Das Testmittel überprüft das System insbesondere mittels eines Testcodes, ob in jeder möglichen Kombination aus LaufZeitdauer und Zeit- punkt jede Zusicherung der Synchronisation gehalten werden kann .

Beispielsweise kann der Entwickler oder Tester, der das erfindungsgemäße Testmittel bedient, angeben, welche Software- einheit zum Testen um welche Zeitdauer verlängert, verlangsamt oder retardiert wird. Dieses Verlängern, Verlangsamen oder Retardieren kann auch sukzessive geschehen, beispielsweise um 5, 15, 20 ms. Des Weiteren kann dieses Verlängern, Verlangsamen oder Retardieren auch prozentual an der Gesamtzeit der Ausführung bemessen werden. Hier ist es vorteilhaft, Anleihen aus bestimmten Optimierungsverfahren, wie beispielsweise Simulated Annealing [13] oder anderen heuristische Me- thoden, zu machen.

Weiter wird vorzugsweise eine Kombination von Softwareeinhei^¬ ten hinsichtlich ihrer LaufZeitdauer verändert, beispielsweise prolongiert. Das Prolongieren selber übernimmt ein Test- Framework des Testmittels mit der speziell konstruierten virtuellen Maschine, um so dem Entwickler oder Tester die Arbeit zu erleichtern und den Test zu automatisieren.

Beispielsweise kann der Entwickler mittels des Testmittels für jede Softwareeinheit einen Vektor angeben, der beschreibt, um welche Zeitdauer oder um wie viel Prozent der Gesamtzeit der Ausführung die jeweilige Softwareeinheit pro^¬ longiert oder retardiert werden soll. Dies ergibt dann für einen speziellen Testfall einen Vektor von Vektoren, welcher das Verhalten der Softwareeinheiten beschreibt.

Mit dem erfindungsgemäßen Testmittel, das beispielsweise ein x-Unit-Test-Framework umfasst, wird das Ergebnis der Prolongation und Retardation überprüft. Gelingt der Test für alle geprüften Intervalle, so ist die Wahrscheinlichkeit für einen Synchronisationsfehler sehr gering. Tritt ein Synchronisationsfehler auf, muss die entsprechende Softwareeinheit einem Reengineering zugeführt werden, um den Fehler zu beseitigen. Die jeweilige Softwareeinheit ist softwaretechnisch implemen^¬ tiert. Die jeweilige Softwareeinheit kann als Computerpro^¬ grammprodukt, als eine Funktion, als eine Routine, als Teil eines Programmcodes, als Modul oder als ein Teil eines Moduls oder als ausführbares Objekt ausgebildet sein.

Weiterhin wird ein Computerprogrammprodukt vorgeschlagen, welches auf einer programmgesteuerten Einrichtung die Durchführung eines wie oben erläuterten Verfahrens zum Testen ei- nes Systems mit zumindest einer Mehrzahl von parallel aus^¬ führbaren Softwareeinheiten veranlasst.

Ein Computerprogramm-Produkt wie ein Computerprogramm-Mittel kann beispielsweise als Speichermedium, wie Speicherkarte,

USB-Stick, Floppy, CD-ROM, DVD oder auch in Form einer herunterladbaren Datei von einem Server in einem Netzwerk bereitgestellt oder geliefert werden. Dies kann zum Beispiel in ei^¬ nem drahtlosen Kommunikationsnetzwerk durch die Übertragung einer entsprechenden Datei mit dem Computerprogramm-Produkt oder dem Computerprogramm-Mittel erfolgen.

Ferner wird eine Vorrichtung zum Testen eines Systems mit zu^¬ mindest einer Mehrzahl von parallel ausführbaren Softwareein- heiten vorgeschlagen, welche zur Ausführung eines Threads und zur Bereitstellung eines gemeinsamen Ergebnisses eingerichtet sind und welche eine jeweilige programmierte LaufZeitdauer der Ausführung haben. Die Vorrichtung hat ein Änderungsmittel zum Ändern einer vorbestimmten LaufZeitdauer zumindest einer Softwareeinheit in eine einstellbare LaufZeitdauer und ein

Testmittel zum Testen des Systems, wobei das Testmittel dazu eingerichtet ist, die zumindest eine einstellbare Laufzeit^¬ dauer zur Detektion von Synchronisationsfehlern des Systems zu variieren.

Das jeweilige Mittel, Änderungsmittel und Testmittel, kann hardwaretechnisch oder auch softwaretechnisch implementiert sein. Bei einer hardwaretechnischen Implementierung kann das jeweilige Mittel als Vorrichtung, zum Beispiel als Computer, Mikroprozessor, Einrichtung oder auch als Teil eines Systems, zum Beispiel als Computer-System, ausgebildet sein. Bei einer softwaretechnischen Implementierung kann das jeweilige Mittel als Computerprogrammprodukt, als eine Funktion, als eine Rou^¬ tine, als Teil eines Programmcodes oder als ausführbares Ob- jekt ausgebildet sein.

Ein aktueller Trend in Wissenschaft und Industrie liegt in der Virtualisierung von Ressourcen und Diensten. Ein Teilge- biet hiervon ist die Visualisierung von Hosts und Betriebs^¬ systemen. Hierbei wird eine Vielzahl so genannter virtueller Maschinen auf einem Endsystem realisiert. Diese virtuellen Maschinen stellen sich für den Nutzer als eigenständige Sys- teme dar. Hierzu werden Hardwareeinheiten und Softwareeinhei^¬ ten nachgebildet und somit virtuell repliziert. In bestehen^¬ den Virtualisierungslösungen werden die virtuellen Hardwareeinheiten oder Hardwarekomponenten so nachgebildet, dass die normale oder korrekte Funktionalität des realen Hardware- Pendants möglichst exakt emuliert wird.

Gemäß der vorliegenden Erfindung wird diese Zielsetzung hinsichtlich Virtualisierung in dem Sinne konterkariert, dass nun die stufenlose und selektive Langsamkeit und Verzögerung als Performanz- oder Leistungsminderung der jeweiligen Softwareeinheit zu einer zentralen Eigenschaft wird. Diese wird explizit in das Testmittel oder den Hypervisor eingebracht. Demnach werden die Softwareeinheiten derart ergänzt oder erweitert, dass deren Performanz individuell und dynamisch vom Testmittel, beispielsweise dem Test-Framework, eingestellt werden kann. Somit werden empirische Experimente auf den Softwaretests möglich. Hierdurch können Synchronisationsfehler bei einem System aus einer Mehrzahl von asynchron arbeitenden Softwareeinheiten kostengünstig aufgefunden werden.

Zusammenfassend liegt der wesentliche Vorteil der vorliegen^¬ den Erfindung darin, dass dedizierte Softwareeinheiten oder Softwaremodule in ihrer Laufzeit verändert werden können. Insbesondere kann die Performanz der Hardwareeinheiten ange- passt werden. Gerade dies kann aber auf einer unterschiedli^¬ chen Hardwareausstattung des Zielsystems zu Synchronisations^¬ fehlern führen.

Erfindungsgemäß kann eine bessere und vor allem realitätsge- treuere Testabdeckung gewährleistet werden. Erfindungsgemäß kann zur Analyse des Synchronisationsverhaltens nicht nur die Reihenfolge geändert werden, sondern insgesamt kann das Ab^¬ laufverhalten, also die Performanzeigenschaften der Module oder Hardwarekomponenten, verändert werden. Somit ist nicht nur das zeitliche Verhalten, sondern auch die Ordnung veränderbar . Folglich ist keine Serialisierung erforderlich, was insbesondere ein Testen auf echt parallelen Plattformen erlaubt und somit die Hardwarebedingungen an den tatsächlichen Zielsystemen besser wider spiegelt. Des Weiteren ist durch die hohe Hardwareheterogenität eine verbesserte Testfallabdeckung ge- währleistet. So treten Synchronisationsfehler durch unterschiedliche Performanzeigenschaften der Hardware auf, was beispielsweise durch die vorgestellte dynamische Analyse nicht abgedeckt werden kann. Durch die vorliegende Erfindung gewinnt ein Analyst, Tester oder Softwareingenieur wertvolle Informationen über mögliche Synchronisationsfehler .

Insgesamt ist es gemäß der vorliegenden Erfindung möglich, auch Situationen zu testen, die herkömmlicher weise bislang vom Testen ausgeschlossen waren. Somit ergeben sich unter anderem die Vorteile, dass eine verbesserte Testfallabdeckung sowie eine Zeitersparnis und eine Kostenersparnis beim Testen erzielt werden können. Insbesondere ermöglicht die vorliegen- de Erfindung durch die Virtualisierung der Umgebung eine Automatisierung des Testens und ein Testen unterschiedlichster Systeme. Daraus resultieren erhebliche Zeit- und Kostener^¬ sparnisse sowie eine höhere Sicherheit und eine Fehlerredu^¬ zierung des getesteten Produkts.

Der Ansatz der vorliegenden Erfindung hat gegenüber den Ansätzen spezieller Programmiersprachen (siehe [2] und [3]) den Vorteil, dass die Erfindung in beliebige Programmiersprachen implementiert werden kann, diese erwähnten speziellen Pro- grammiersprachen allerdings nicht generell akzeptiert sind (siehe [ 7 ] ) .

Gemäß einem als Modelchecking bekannten Ansatz (siehe [11]) muss erfindungsgemäß kein formales Model oder eine Formel spezifiziert werden. Des Weiteren sind mittels Modelchecking nur kleinere Systeme verifizierbar. Die vorliegende Erfindung hingegen ist für die Softwareindustrie und damit auch für größere Projekte besser geeignet. Mittels Model-checking kön^¬ nen zwar Synchronisationsfehler aufgefunden werden, das zu testende System muss allerdings als Formel oder Systembe^¬ schreibung vorliegen, was im industriellen Umfeld eher selten der Fall ist. Des Weiteren wächst der Zustandsraum meist überproportional mit der Größe des zu testenden Systems. Da^¬ mit sind nur kleinere Systeme oder Programme mittels Model- checking verifizierbar. Die Gründe hierin liegen insbesondere in der notwendigen Speichergröße und einem unverhältnismäßig langen Zeitbedarf.

Im Weiteren sollen die Vorteile der vorliegenden Erfindung gegenüber statischen Analyse-Methoden detailliert erläutert werden. Herkömmlicherweise existiert eine Klasse von Program^¬ mierwerkzeugen, beispielsweise die Werkzeuge "FindBug" [1] und "RacerX" [5], die nach statischen Mustern im Softwarecode sucht. Neben der Fehleranfälligkeit der sogenannte "False Po^¬ sitives", das heißt aufgefundene Fehler, die tatsächlich kei^¬ ne solchen sind, hat der Ansatz der statischen Analyse weiterhin die folgenden Nachteile:

Der Code oder Softwarecode muss als Ganzes vorliegen. Die

Entwicklung größerer Projekte basiert allerdings auf der Wie^¬ derverwendung von bestehenden Codebauteilen, wie beispielsweise Bibliotheken, welche oftmals auch von Drittanbietern kommen. Diese Drittanbieter sind in der Regel nicht bereit, ihren Softwarecode und ihre Bibliotheken offenzulegen. Des

Weiteren können bei einer statischen Analyse Konflikte in Zusammenhang mit Routinen des Betriebssystems nicht analysiert werden. Weiterhin kann mittels statischen Analysen das jeweils aktuelle Verhalten auf einem realen oder potenziell möglichen System nicht untersucht werden. So können unnötige Synchronisationsmechanismen den Softwarecode vorliegen, die das System tatsächlich unnötig verlangsamen können, oder Synchronisationsprobleme können durch die verwendende Hardware entstehen. Des Weiteren sind große Softwareprodukte herkömm^¬ licherweise oftmals in unterschiedlichen Programmiersprachen implementiert, was eine statische Analyse deutlich erschwert. Erfindungsgemäß kann gegenüber solchen statischen Analyse- Methoden eine deutliche Zeitersparnis erreicht werden. Ferner muss erfindungsgemäß nicht der gesamte Code oder Softwarecode vollständig vorliegen. Es besteht erfindungsgemäß auch nicht das Erfordernis, dass dieser Code in einer einzigen Program- miersprache implementiert vorliegt, weil erfindungsgemäß em^¬ pirisch getestet wird. Ein weiterer Vorteil liegt darin, dass keine sogenannten "False Positives" gefunden werden.

Weiter werden im Folgenden die erfindungsgemäßen Vorteile ge- genüber einer dynamischen Analyse durch Ausführen potenziell möglicher Thread-Interleavings aufgezeigt.

Ein Beispiel für eine dynamische Analyse durch Ausführen po^¬ tenziell möglicher Thread-Interleavings ist als das Werkzeug "Chess" bekannt [9] . "Chess" reduziert die möglichen Pre- emptions, um einer Explosion des Zustandsraumes der möglichen Thread-Interleavings vorzubeugen [9]; Seite 9]. Allerdings besteht eine Wahrscheinlichkeit dafür, dass gerade speziell durch diese Pre-emptions Synchronisationsfehler und Race- Conditions nachteiligerweise auftreten.

"Chess" ordnet mögliche Ausführungskombinationen um und erzwingt die Ausführung "Single-Threaded" [9]; Seite 7]. In dieser Zitatstelle ist weiter erwähnt, dass dadurch keine vollständige Abdeckung von Data Races möglich ist, was zu ei^¬ nigen nicht aufgefundenen Fehlern führen kann. Ein weiteres Problem des Tools "Chess" liegt in echter Hardwareparalleli^¬ tät. Es ist wahrscheinlich, dass bei einer echten Paralleli^¬ tät im Gegensatz zu einer Pseudoparallelität Fehler auftre- ten, die durch die Permutation der möglichen Ausführungsreihenfolgen nicht gefunden werden kann.

Im Weiteren werden die erfindungsgemäßen Vorteile gegenüber einer dynamischen Analyse von Data Races diskutiert. Aus der Veröffentlichung [14] ist das Tool "Race Track" bekannt, mit^¬ tels dem Data Races gefunden werden können. Hierbei wird eine virtuelle Maschine instrumentiert. Die Aktionen des Programms werden protokolliert und potenzielle Data Races werden refe^¬ riert. Allerdings wird in [14; Seite 1] darauf hingewiesen, dass durch den dynamischen Ansatz nur eine Teilmenge aller möglichen Data Races gefunden werden kann, da nicht alle möglichen Ausführungspfade betrachtet werden. Auf anderen Ziel- Systemen mit anderen (Hardware-) Eigenschaften kann dies entscheidend sein, da sich die Ausführungspfade aufgrund der ge^¬ änderten Hardwareeigenschaften unterscheiden können. Der erfindungsgemäße Ansatz deckt diese durch eine deutlich größere Menge an Ausführungspfaden ab, da die LaufZeiteigenschaften der einzelnen Module variiert werden.

Vorteilhafte Ausgestaltungen und Weiterbildungen der Erfindung ergeben sich aus den Unteransprüchen sowie der Beschreibung unter Bezugnahme auf die Zeichnungen.

Gemäß einer bevorzugten Weiterbildung werden vorbestimmte LaufZeiteigenschaften der Ausführung der jeweiligen Softwareeinheit durch die programmierte LaufZeitdauer der Ausführung der jeweiligen Softwareeinheit, durch einen StartZeitpunkt der Ausführung und durch einen Endzeitpunkt der Ausführung ausgebildet .

Gemäß einer weiteren bevorzugten Weiterbildung wird die programmierte LaufZeitdauer zumindest einer Softwareeinheit in eine einstellbare LaufZeitdauer geändert.

Gemäß einer weiteren bevorzugten Weiterbildung wird der vorbestimmte StartZeitpunkt zumindest einer Softwareeinheit in einen einstellbaren StartZeitpunkt geändert.

Gemäß einer weiteren bevorzugten Weiterbildung wird der vorbestimmte Endzeitpunkt zumindest einer Softwareeinheit in ei^¬ nen einstellbaren Endzeitpunkt geändert. Somit können vorteilhafterweise Start- und Endzeitpunkt sowie LaufZeitdauer künstlich variiert werden, um nach relativ kurzer Zeit Synchronisationsfehler zu reproduzieren und damit aufzufinden.

Gemäß einer weiteren bevorzugten Weiterbildung beinhaltet das Testen des Systems ein Variieren der zumindest einen einstellbaren LaufZeitdauer und ein Variieren des zumindest ei- nen einstellbaren StartZeitpunkt und/oder ein Variieren des zumindest einen einstellbaren Endzeitpunktes.

Beispielsweise wird der Ausführungszeitpunkt der Softwareein^¬ heiten zeitlich verzögert. Dies entspricht beispielsweise dem Fall, dass eine Softwareeinheit nicht zum vordefinierten

Zeitpunkt ausführbar ist. Dies wird als Retardieren bezeichnet .

Des Weiteren kann die Ausführungsdauer der Softwareeinheit verlängert werden. Dies entspricht beispielsweise dem Fall, wenn eine Softwareeinheit länger für die Bearbeitung einer vorbestimmten Aufgabe braucht. Dies wird als Prolongieren be^¬ zeichnet . Gemäß einer weiteren bevorzugten Weiterbildung wird das Ändern zumindest einer der Laufzeiteigenschaften der Ausführung der jeweiligen Softwareeinheit zur Bereitstellung zumindest einer einstellbaren Laufzeiteigenschaft durch ein Ändern eines Codes der jeweiligen Softwareeinheit ausgebildet.

Gemäß einer weiteren bevorzugten Weiterbildung wird das Ändern zumindest einer der Laufzeiteigenschaften der Ausführung der jeweiligen Softwareeinheit zur Bereitstellung zumindest einer einstellbaren Laufzeiteigenschaft ausgebildet durch: - Bereitstellen einer Anzahl von Hardwareeinheiten, welche dazu eingerichtet sind, die Softwareeinheiten abzuarbeiten;

Nachbilden der jeweiligen Hardwareeinheit zur Bereitstellung einer jeweiligen nachgebildeten Hardwareeinheit; und Erweitern der jeweiligen nachgebildeten Hardwareeinheit derart, dass zumindest eine der LaufZeiteigenschaften der nachgebildeten Hardwareeinheit, durch welche das jeweilige Softwaremittel zum Ausführungszeitpunkt des Softwaremittels abgearbeitet wird, einstellbar ist.

Die jeweilige nachgebildete, insbesondere virtualisierte oder emulierte, Hardwareeinheit ist softwaretechnisch implemen^¬ tiert. Die jeweilige nachgebildete Hardwareeinheit kann als Computerprogramm-Produkt, als Teil eines Programmcodes, als Modul oder als Teil eines Moduls oder als ein ausführbares Objekt ausgebildet sein.

Vorteilhafterweise werden die nachgebildeten Hardwareeinhei- ten, beispielsweise virtualisierte Hardwarekomponenten, der^¬ art ergänzt oder erweitert, dass deren Performanz individuell und dynamisch von dem Testmittel eingestellt werden kann, um unzureichende Synchronisationen des Systems zu detektieren. Zur Steuerung der Performance-Eigenschaften wird erfindungsgemäß das Testmittel um Schnittstellen erweitert, die aus dem Test-Framework zugreifbar sind. Somit kann für ein Test- Framework die Performanz der Softwareeinheiten und der nachgebildeten Hardwareeinheiten feingranular, beispielsweise bis auf Mikrobefehlsebene, und dynamisch eingestellt werden.

Damit wird die Testmethodik für ein System erfindungsgemäß grundsätzlich erweitert. Software ist anfällig für Race Con- ditions und Synchronisationsfehler. Diese Fehler können her- kömmlicherweise nur zufällig in einem herkömmlichen Testpro- zess entdeckt werden.

Damit vermindert die vorliegende Erfindung die Gefahr, dass diese Fehler nicht aufgefunden werden, insbesondere wenn sich die Zielsysteme von den Test- und Entwicklungssystemen unterscheiden. Insbesondere kann auf dem Zielsystem eine andere Konfiguration wie auf dem Test- und Entwicklungssystem verwendet werden. Gemäß einer weiteren bevorzugten Weiterbildung wird das Nachbilden der jeweiligen Hardwareeinheit als ein Virtualisieren oder als ein Emulieren ausgebildet.

Gemäß einer weiteren bevorzugten Weiterbildung wird das Testen des Systems zur Bereitstellung von Testergebnisdaten durchgeführt, wobei eine vorbestimmbare Anzahl von vorbe^¬ stimmten und zu untersuchenden Synchronisations-Maßnahmen zur Synchronisation der Softwareeinheiten während des Testens unterbunden wird und das Testen mit den unterbundenen Synchronisationsmaßnahmen zu Ende geführt wird, wobei die bereitge^¬ stellten Testergebnisdaten zur Detektion von unnötigen Synchronisationsmaßnahmen validiert werden.

Synchronisation wird vorzugsweise als Sicherheitsmechanismus eingesetzt, kann ein System aber auch verlangsamen. Eine Synchronisation sperrt ein Objekt, so dass andere parallele Aus^¬ führungen nicht auf dieses Objekt zugreifen können. Der

Overhead der Synchronisation ist beispielsweise durch jüngste Forschung (z.B. [6]) deutlich verbessert, jedoch wird teilweise bei der Programmierung zu viel Synchronisation verwendet, welche das System wiederum verlangsamen kann. Vorliegend wird bei der Ausführung des Systems in einer dedi- zierten Art und Weise zumindest eine zu untersuchende Syn^¬ chronisations-Maßnahme unterbunden, um insbesondere Race Con- ditions zu detektieren, denn nur die potenziell möglichen Race Conditions verlangen eine Synchronisation.

Gemäß einer weiteren bevorzugten Weiterbildung werden die durch das Testen untersuchten Synchronisationsmaßnahmen bei einer positiven Validierung der bereitgestellten Testergebnisdaten als unnötige Synchronisationsmaßnahmen bestimmt.

Gemäß einer weiteren bevorzugten Weiterbildung wird das Variieren der zumindest einer einstellbaren LaufZeitdauer als ein Verlängern der LaufZeitdauer um eine vorbestimmbare Zeitdauer ausgebildet .

Für weitere Tests ist es vorteilhafterweise sinnvoll, eine Kombination von Softwareeinheiten zu prolongieren. Das Pro- longieren selbst wird durch das erfindungsgemäße Testmittel durchgeführt. Das erfindungsgemäße Testmittel umfasst insbe^¬ sondere eine speziell konstruierte virtuelle Maschine, um so dem Entwickler oder Tester die Arbeit zu erleichtern und den Test zu automatisieren.

Beispielsweise kann der Entwickler mittels des Testmittels für jede Softwareeinheit einen Vektor angeben, der beschreibt, um welche Zeitdauer oder um wie viel Prozent der Gesamtzeit der Ausführung die jeweilige Softwareeinheit pro- longiert oder retardiert werden soll. Dies ergibt dann für einen speziellen Testfall einen Vektor von Vektoren, welcher das Verhalten der Softwareeinheiten beschreibt.

Ferner wird hier eine Erweiterung um simuliertes Optimieren vorgeschlagen, um auch durch die Prolongation Verkürzungen der Ausführungszeit zu ermöglichen.

Gemäß einer weiteren bevorzugten Weiterbildung wird eine Mehrzahl von vorbestimmten LaufZeitdauern einer Mehrzahl von Softwareeinheiten zur Bereitstellung von jeweils einstellbaren LaufZeitdauern geändert.

Somit können vorteilhafterweise bei der Mehrzahl asynchron arbeitender Softwareeinheiten Synchronisationsfehler aufge- funden werden.

Gemäß einer weiteren bevorzugten Weiterbildung beinhaltet das Testen ein Variieren der Mehrzahl der einstellbaren Laufzeitdauern der Mehrzahl der Softwareeinheiten.

Die Erfindung wird nachfolgend anhand der in den schemati^¬ schen Figuren angegebenen Ausführungsbeispiele näher erläutert. Es zeigen: Fig. 1 ein schematisches Ablaufdiagramm eines ersten

Ausführungsbeispiels eines Verfahrens zum Testen eines Systems mit einer Mehrzahl von parallel ausführbaren Softwareeinheiten;

Fig. 2 ein schematisches Ablaufdiagramm eines zweiten

Ausführungsbeispiels eines Verfahrens zum Testen eines Systems mit einer Mehrzahl von parallel ausführbaren Softwareeinheiten; ein schematisches Ablaufdiagramm eines dritten Ausführungsbeispiels eines Verfahrens zum Testen eines Systems mit einer Mehrzahl von parallel ausführbaren Softwareeinheiten; und

Fig. 4 ein schematisches Blockschaltbild eines Ausfüh^¬ rungsbeispiels einer Vorrichtung zum Testen eines Systems mit einer Mehrzahl von parallel ausführ- baren Softwareeinheiten.

In allen Figuren sind gleiche bzw. funktionsgleiche Mittel und Einrichtungen - sofern nichts anderes angegeben - mit denselben Bezugszeichen versehen.

Fig. 1 zeigt ein schematisches Ablaufdiagramm eines ersten Ausführungsbeispiels eines Verfahrens zum Testen eines Sys^¬ tems mit einer Mehrzahl von parallel ausführbaren Softwareeinheiten .

Die parallel ausführbaren Softwareeinheiten sind zur jeweiligen Ausführung eines Threads und zur Bereitstellung eines gemeinsamen Ergebnisses eingerichtet. Die jeweilige Software^¬ einheit hat eine jeweilige programmierte oder codierte Lauf- Zeitdauer der Ausführung. Weiter umfasst die jeweilige Softwareeinheit beispielsweise ein Programm und Daten.

Das erste Ausführungsbeispiel des erfindungsgemäßen Verfah- rens gemäß Fig. 1 hat folgende Verfahrensschritte 101 bis 103:

Verfahrensschritt 101:

Die programmierte LaufZeitdauer zumindest einer Softwareeinheit wird in eine einstellbare LaufZeitdauer geändert.

Verfahrensschritt 102:

Ein Testmittel 3 (siehe Fig. 3) zum Validieren des Systems und zum Einstellen der zumindest einen einstellbaren Laufzeitdauer wird bereitgestellt. Verfahrensschritt 103:

Das System wird mittels des Testmittels zur Bereitstellung von Testergebnissen getestet. Das Testen beinhaltet ein Variieren der zumindest einen einstellbaren LaufZeitdauer zur De- tektion von Synchronisationsfehlern des Systems.

Vorzugsweise ist das Variieren der zumindest einen einstell^¬ baren LaufZeitdauer als ein Verlängern der LaufZeitdauer um eine vorbestimmte Zeitdauer ausgebildet. Des Weiteren kann das Variieren auch als ein Verkürzen der LaufZeitdauer um eine vorbestimmte oder vorbestimmbare Zeitdauer ausgebildet sein .

Fig. 2 zeigt ein schematisches Ablaufdiagramm eines zweiten Ausführungsbeispiels eines Verfahrens zum Testen eines Sys^¬ tems mit einer Mehrzahl von parallel ausführbaren Softwareeinheiten, welche zur jeweiligen Ausführung eines Threads und zur Bereitstellung eines gemeinsamen Ergebnisses eingerichtet sind und welche eine jeweilige programmierte LaufZeitdauer der Ausführung haben.

Das zweite Ausführungsbeispiel der Fig. 2 hat die Verfahrens^¬ schritte 201-203. Verfahrensschritt 201:

Es werden verschiedene programmierte LaufZeiteigenschaften der Ausführung der jeweiligen Softwareeinheit geändert. Die vorbestimmten oder programmierten LaufZeiteigenschaften sind durch die vorbestimmte LaufZeitdauer der Ausführung der jeweiligen Softwareeinheit, durch einen StartZeitpunkt der Aus^¬ führung und durch einen Endzeitpunkt der Ausführung ausgebil- det.

Dabei wird die vorbestimmte LaufZeitdauer zumindest einer Softwareeinheit in eine einstellbare LaufZeiteinheit geän^¬ dert. Zusätzlich wird vorzugsweise der vorbestimmte Start- Zeitpunkt zumindest einer Softwareeinheit in einen einstell^¬ baren StartZeitpunkt geändert. Zusätzlich oder alternativ wird auch der vorbestimmte Endzeitpunkt zumindest einer Soft^¬ wareeinheit in einen einstellbaren Endzeitpunkt geändert. Das Ändern zumindest einer der LaufZeiteigenschaften der Ausführung der jeweiligen Softwareeinheit ist beispielsweise durch ein Ändern eines Codes der jeweiligen Softwareeinheit ausgebildet . Alternativ oder zusätzlich kann das Ändern zumindest einer der LaufZeiteigenschaften der Ausführung der jeweiligen Softwareeinheit zur Bereitstellung zumindest einer einstellbaren Laufzeiteigenschaft durch folgende Teilschritte ausgebildet sein: Eine Anzahl von Hardwareeinheiten wird bereitgestellt, welche dazu eingerichtet sind, die Softwareeinheiten abzuar^¬ beiten. Die jeweilige Hardwareeinheit wird zur Bereitstellung einer jeweiligen nachgebildeten Hardwareeinheit nachgebildet. Das Nachbilden kann ein Virtualisieren oder ein Emulieren sein. Weiter wird die jeweilige nachgebildete Hardwareeinheit derart erweitert, dass zumindest einer der Laufzeiteigen- schaften der nachgebildeten Hardwareeinheit, durch welche das jeweilige Softwaremittel zum Ausführungszeitpunkt des Soft^¬ waremittels abgearbeitet wird, einstellbar ist. Die jeweilige Hardwareeinheit ist beispielsweise als Computer, Mikroprozes^¬ sor, Einrichtung oder auch als Teil eines Computersystems ausgebildet . Verfahrensschritt 202:

Ein Testmittel 3 (siehe Fig. 3) wird zum Validieren des Sys^¬ tems und zum Einstellen der einstellbaren Laufzeiteigenschaf- ten bereitgestellt.

Verfahrensschritt 203:

Das System wird zur Bereitstellung von Testergebnisdaten getestet. Dabei wird eine vorbestimmbare Anzahl von vorbestimm- ten und zu untersuchenden Synchronisationsmaßnahmen zur Synchronisation der Softwareeinheiten während des Testens unterbunden. Das Testen wird mit den unterbundenen Synchronisationsmaßnahme zu Ende geführt, wobei die bereitgestellten Test^¬ ergebnisdaten zur Detektion von unnötigen Synchronisations- maßnahmen validiert werden.

In Fig. 3 ist ein schematisches Ablaufdiagramm eines dritten Ausführungsbeispiels eines Verfahrens zum Testen eine Systems mit einer Mehrzahl von parallel ausführbaren Softwareeinhei- ten dargestellt.

Das dritte Ausführungsbeispiel basiert auf dem ersten Ausfüh^¬ rungsbeispiel gemäß Fig. 1 und umfasst sämtliche mit Bezug zu Fig. 1 dargestellten Merkmale. Das dritte Ausführungsbeispiel der Fig. 3 hat die Verfahrensschritte 301 bis 303:

Verfahrensschritt 301:

Eine Mehrzahl von programmierten oder vorbestimmten Laufzeit- dauern einer Mehrzahl von Softwareeinheiten wird zur Bereitstellung von jeweils einstellbaren LaufZeitdauern geändert.

Verfahrensschritt 302: Ein Testmittel 3 (siehe Fig. 3) zum Validieren des Systems und zum Einstellen der zumindest einen einstellbaren Laufzeitdauer wird bereitgestellt.

Verfahrensschritt 303:

Das Testen des Systems wird mittels des Testmittels durchge^¬ führt, wobei das Testen ein Variieren der Mehrzahl der ein- stellbaren LaufZeitdauern der Mehrzahl der Softwareeinheiten zur Detektion von Synchronisationsfehlern des Systems beinhaltet .

Fig. 4 zeigt ein schematisches Blockschaltbild eines Ausfüh- rungsbeispiels einer Vorrichtung 1 zum Testen eines Systems mit einer Mehrzahl von parallel ausführbaren Softwareeinheiten. Die parallel ausführbaren Softwareeinheiten sind zur Ausführung eines Threads und zur Bereitstellung eines gemeinsamen Ergebnisses eingerichtet und haben eine jeweilige pro- grammierte LaufZeitdauer der Ausführung.

Die Vorrichtung hat zumindest ein Änderungsmittel 2 und ein Testmittel 3. Das Änderungsmittel 2 ist dazu eingerichtet, eine program^¬ mierte oder vorbestimmte LaufZeitdauer zumindest einer Soft^¬ wareeinheit in eine einstellbare LaufZeitdauer zu ändern. Da^¬ mit stellt das Änderungsmittel 2 ausgangsseitig zumindest ei^¬ ne geänderte Softwareeinheit 4 bereit.

Das Testmittel 3 ist dazu eingerichtet, das System zur Be^¬ reitstellung von Testergebnisdaten 5 zu testen. Dabei ist das Testen dazu eingerichtet, die zumindest eine einstellbare LaufZeitdauer der zumindest einen geänderten Softwareeinheit 4 zur Detektion von Synchronisationsfehlern des Systems zu variieren .

Obwohl die vorliegende Erfindung vorstehend anhand der bevor- zugten Ausführungsbeispiele beschrieben wurde, ist sie darauf nicht beschränkt, sondern auf vielfältige Art und Weise modi^¬ fizierbar .

Literaturliste

[1] Ayewah, Nathaniel; Hovemeyer, David; Morgenthaler, J.D.;

Penix, John; Pugh, William: Using Static Analysis to Find Bugs. In: IEEE Software 25 (2008), No . 5, Se. 22-

29.

http : //dx . doi . org/http : //doi . ieeecomputersociety. org/10. 1109/MS.2008.130.-

DOIhttp: //doi . ieeecomputersociety . org/10.1109/MS .2008.13 0.-ISSN 0740-7459

[2] Bacon, David F.; Strom, Robert E . ; Tarafdar, Ashis:

Guava: A dialect of Java without data races. In: In Ob^¬ ject-Oriented Programming, Systems, Languages, and Ap- plications (OOPSLA, ACM Press, 2000, S. 382-400

[3] Boyapati, Chandrasekhar ; Lee, Robert; Rinard, Martin:

Ownership types for safe programming: preventing data races and deadlocks. In: OOPSLA '02: Proceedings of the 17^th ACM SIGPLAN Conference on Obj ectoriented program^¬ ming, Systems, languages, and applications Bd. 37. ew York, NY, USA: ACM Press, November 2002. -ISBN

1581134711, 211-230 [4] Choi, Jong-Dek; Lee, Keunwoo; loginov, Alexey; O'Calla- han; Robert; Sarkar, Vivek; Sridharan, Manu: Efficient and precise datarace detection for multithreaded object- oriented programs . In: PLDI'02: Proceedings of the ACM SIGPLAN 2002 Conference on Programming language design an Implementation. New York, NY, USA: ACM, 2002. -ISBN 1-

58113-463-0, S. 258-269

[5] Engler, Dawson; Ashcraft, Ken: RacerX: effective, static detection of race conditions and deadlocks. In: SIGOPS Oper. Syst. Rev. 37 (2003), Nr. 5, S. 237-252.

http://dx.doi . org/http : //doi . acm. org/10.1145/1165389.945 468. -DOI http: //doi .acm. org/10.1145/1165389.945468. -ISSN 0163-5980 [6] Hohmuth, Michael; Härtig, Hermann: Pragmatic Nonblocking Synchronization for Real-Time Systems. In: Proceedings of the General Track: 2002 USENIX Annual Technical Con- ference. Berkeley, CA, USA: USENIX Association, 2001.-

ISBN 1-880446-09-X, S.217-230.

[7] Hovemeyer, David; Pugh, William: Finding concurrency

bugs in Java. In: In Proceedings of the PODC Workshop on Concurrency and Synchronization in Java Programs, 2004.

[8] Florian Mangold. Performanzanalyse mit Hilfe künstlicher Varianz. Diplomarbeit, Ludwig-Maximilians-Universität, Munich, May 2007.

[9] Musuvathi, Madanlal; Qadeer, Shaz; Ball, Thomas; Basler, Gerard; Ninar, Piramanayagam A. ; Naemtiu, Iulian: Finding and Reproducing Heisenbugs in Concurrent Programs. In: Draves, Richard (Hrsg.); Renesse, Robbert van

(Hrsg.): OSDI, USENIX Association, 2008. -ISBN 978-1-

931971-65-2, 267-280

[10] Netzer, Robert H.B.; Miller, Barton P.: What are race conditions? some issues and formalizations . In: ACM Let- ters on Programming Languages and Systems 1 (1992),

S.74-88.

[11] Stoller, Scott D.: Testing Concurrent Java Programs us- ing Randomized Scheduling. In: Proc. Second Workshop on Runtime Verification (RV) Bd. 70(4), Elsevier, Juli 2002

(Electronic Notes in Theoretical Computer Science)

[12] Yourdon Edward, Larry L. C: Structured Design: Funda^¬ mentals of a Discipline of Computer Program and Systems Design. Englewood Cliffs, NJ: Prentice Hall, 1979

[13] Laarhoven, P.J.M., Aarts, E.H.L. "Simulated Annealing:

Theory and Applications", Norwell, MA, USA, Kluwer Aca- demic Publishers, 1987

[14] Yu, Yuan; Rodeheffer, Tom; Chen, Wei: Race Track: Effi- cient Detection of Data Race Conditions via Adaptive Tracking. in: SOSP '05: Proceedings of the twentieth ACM

Symposium on Operating Systems principles. New York, NY, USA; ACM Press, 2005, 221- 234

Claims

Patentansprüche

Verfahren zum Testen eines Systems mit zumindest einer Mehrzahl von parallel ausführbaren Softwareeinheiten, welche zur jeweiligen Ausführung eines Threads und zur Bereitstellung eines gemeinsamen Ergebnisses eingerichtet sind und welche eine jeweilige programmierte Laufzeitdau^¬ er der Ausführung haben, mit den Schritten:

a) Ändern der vorbestimmten LaufZeitdauer zumindest einer Softwareeinheit in eine einstellbare Laufzeitdau^¬ er (101);

b) Bereitstellen eines Testmittels (3) zum Validieren des Systems und zum Einstellen der zumindest einen einstellbaren LaufZeitdauer (102); und

c) Testen des Systems mittels des Testmittels, wobei das Testen ein Variieren der zumindest einen einstellbaren LaufZeitdauer zur Detektion von Synchronisationsfehlern des Systems beinhaltet (103) .

Verfahren nach Anspruch 1,

dadurch gekennzeichnet,

dass programmierte Laufzeiteigenschaften der Ausführung der jeweiligen Softwareeinheit durch die programmierte LaufZeitdauer der Ausführung der jeweiligen Softwareeinheit, durch einen StartZeitpunkt der Ausführung und durch einen Endzeitpunkt der Ausführung ausgebildet werden (201) .

Verfahren nach Anspruch 2,

dadurch gekennzeichnet,

dass die programmierte LaufZeitdauer zumindest einer Softwareeinheit in eine einstellbare LaufZeitdauer geän^¬ dert wird und

dass der vorbestimmte StartZeitpunkt zumindest einer Softwareeinheit in einen einstellbaren StartZeitpunkt ge^¬ ändert wird und/oder dass der vorbestimmte Endzeitpunkt zumindest einer Soft^¬ wareeinheit in einen einstellbaren Endzeitpunkt geändert wird (201) .

Verfahren nach Anspruch 3,

dadurch gekennzeichnet,

dass das Testen des Systems ein Variieren der zumindest einen einstellbaren LaufZeitdauer und ein Variieren des zumindest einen einstellbaren StartZeitpunkt und/oder ein Variieren des zumindest einen einstellbaren Endzeitpunktes beinhaltet (203) .

Verfahren nach einem der Ansprüche 2-4,

dadurch gekennzeichnet,

dass das Ändern zumindest einer der LaufZeiteigenschaften der Ausführung der jeweiligen Softwareeinheit zur Bereitstellung zumindest einer einstellbaren Laufzeiteigen- schaft ausgebildet wird durch:

Ändern eines Codes der jeweiligen Softwareeinheit (201).

Verfahren nach einem der Ansprüche 2-4,

dadurch gekennzeichnet,

dass das Ändern zumindest einer der LaufZeiteigenschaften der Ausführung der jeweiligen Softwareeinheit zur Bereitstellung zumindest einer einstellbaren Laufzeiteigen- schaft ausgebildet wird (201) :

Bereitstellen einer Anzahl von Hardwareeinheiten, welche dazu eingerichtet sind, die Softwareeinheiten abzuarbeiten;

Nachbilden der jeweiligen Hardwareeinheit zur Bereitstellung einer jeweiligen nachgebildeten Hardwareeinheit; und

Erweitern der jeweiligen nachgebildeten Hardwareeinheit derart, dass zumindest eine der Laufzeiteigen- schaften der nachgebildeten Hardwareeinheit, durch welche das jeweilige Softwaremittel zum Ausführungs^¬ zeitpunkt des Softwaremittels abgearbeitet wird, ein^¬ stellbar ist. Verfahren nach Anspruch 6,

dadurch gekennzeichnet,

dass das Nachbilden der jeweiligen Hardwareeinheit als ein Virtualisieren oder als ein Emulieren ausgebildet wird .

Verfahren nach einem der vorstehenden Ansprüche,

dadurch gekennzeichnet,

dass das Testen des Systems zur Bereitstellung von Testergebnisdaten durchgeführt wird, wobei eine vorbestimmba^¬ re Anzahl von vorbestimmten und zu untersuchenden Synchronisations-Maßnahmen zur Synchronisation der Softwareeinheiten während des Testens unterbunden wird und das Testen mit den unterbundenen Synchronisationsmaßnahmen zu Ende geführt wird, wobei die bereitgestellten Testergeb^¬ nisdaten zur Detektion von unnötigen Synchronisationsmaßnahmen validiert werden (203) . Verfahren nach Anspruch 8,

dadurch gekennzeichnet,

dass die durch das Testen untersuchten Synchronisations^¬ maßnahmen bei einer positiven Validierung der bereitgestellten Testergebnisdaten als unnötige Synchronisations- maßnahmen bestimmt werden (203) .

Verfahren nach einem der vorstehenden Ansprüche,

dadurch gekennzeichnet,

dass das Variieren der zumindest einer einstellbaren LaufZeitdauer als ein Verlängern der LaufZeitdauer um eine vorbestimmbare Zeitdauer ausgebildet wird.

Verfahren nach einem der vorstehenden Ansprüche,

dadurch gekennzeichnet,

dass eine Mehrzahl von vorbestimmten LaufZeitdauern einer Mehrzahl von Softwareeinheiten zur Bereitstellung von jeweils einstellbaren LaufZeitdauern geändert wird (301).

12. Verfahren nach Anspruch 11,

dadurch gekennzeichnet,

dass das Testen ein Variieren der Mehrzahl der einstellbaren LaufZeitdauern der Mehrzahl der Softwareeinheiten beinhaltet (303) .

13. Computerprogrammprodukt, welches auf einer programmge^¬ steuerten Einrichtung die Durchführung eines Verfahrens nach einem der Ansprüche 1-12 veranlasst.

14. Vorrichtung (1) zum Testen eines Systems mit zumindest einer Mehrzahl von parallel ausführbaren Softwareeinheiten, welche zur Ausführung eines Threads und zur Bereit^¬ stellung eines gemeinsamen Ergebnisses eingerichtet sind und welche eine jeweilige programmierte LaufZeitdauer der Ausführung haben, mit:

a) einem Änderungsmittel (2) zum Ändern einer vorbe^¬ stimmten LaufZeitdauer zumindest einer Softwareeinheit in eine einstellbare LaufZeitdauer ; und b) einem Testmittel (3) zum Testen des Systems, wobei das Testmittel dazu eingerichtet ist, die zumindest eine einstellbare LaufZeitdauer zur Detektion von Synchronisationsfehlern des Systems zu variieren.