DE102009050161A1

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

Info

Publication number: DE102009050161A1
Application number: DE200910050161
Authority: DE
Inventors: Florian Mangold; Harald Dr. Rölle
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2009-10-21
Filing date: 2009-10-21
Publication date: 2011-04-28
Also published as: US8972784B2; WO2011047901A1; US20120278660A1

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

Die Erfindung betrifft ein Verfahren und eine Vorrichtung zum Testen eines Systems mit zumindest einer Mehrzahl von parallel 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 Softwareeinheiten 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 durchgeführt werden. Bei einer sequenziellen Ausführung ist dies nicht möglich. Durch eine parallele Ausführung steht das gesamte Softwaresystem damit schneller wieder für eine neue Benutzerinteraktion bereit. Damit wirkt das System performanter, 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 anderem zur verbesserten Benutzerinteraktion eingesetzt. Solche Multitasking-Systeme müssen auch softwaretechnisch entsprechend auf Multitasking, also auf eine parallele Abarbeitung von zusammenhängenden Anweisungen oder Threads, konstruiert und implementiert werden. Die Perspektive hier ist die Performanzsteigerung eines Systems mit potenziell einer Mehrzahl gleichzeitig ausgeführter Programme.
Somit müssen zur Effizienzsteigerung und aufgrund neuer Rechnerarchitekturen Softwaresysteme hinsichtlich paralleler Abarbeitung konstruiert und implementiert werden. Beispielsweise 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 überblicken. 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 Synchronisationsfehler eher die Regel als die Ausnahme.
Demnach ist es eine Aufgabe der vorliegenden Erfindung, eine verbesserte Möglichkeit zur Detektion von Synchronisationsfehlern eines Systems mit einer Mehrzahl asynchron arbeitender Softwareeinheiten zu schaffen.
Erfindungsgemäß wird diese gestellte Aufgabe durch ein Verfahren 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 zumindest einer Mehrzahl von parallel ausführbaren Softwareeinheiten 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 Hardwareeinheiten 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. Erfindungsgemäß wird damit ein herkömmlicher Softwaretest mit einem 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 Komponente 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 Virtualisierung und/oder die Emulierung, möglich. Da ein System aus unterschiedlichsten Softwareeinheiten bestehen kann, können die Laufzeiteigenschaften unterschiedlichster Softwareeinheiten variiert und beobachtet werden.
Dabei umfasst das Variieren insbesondere ein mehrmaliges, aufeinanderfolgendes Einstellen der jeweiligen Laufzeiteigenschaft.
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 jeweiligen 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 Zeitpunkt jede Zusicherung der Synchronisation gehalten werden kann.
Beispielsweise kann der Entwickler oder Tester, der das erfindungsgemäße Testmittel bedient, angeben, welche Softwareeinheit 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 Methoden, zu machen.
Weiter wird vorzugsweise eine Kombination von Softwareeinheiten 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 prolongiert 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 implementiert. Die jeweilige Softwareeinheit kann als Computerprogrammprodukt, 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 eines Systems mit zumindest einer Mehrzahl von parallel ausfü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 einem 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 zumindest einer Mehrzahl von parallel ausführbaren Softwareeinheiten 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 Laufzeitdauer 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 Routine, als Teil eines Programmcodes oder als ausführbares Objektausgebildet sein.
Ein aktueller Trend in Wissenschaft und Industrie liegt in der Virtualisierung von Ressourcen und Diensten. Ein Teilgebiet hiervon ist die Virtualisierung von Hosts und Betriebssystemen. Hierbei wird eine Vielzahl so genannter virtueller Maschinen auf einem Endsystem realisiert. Diese virtuellen Maschinenstellen sich für den Nutzer als eigenständige Systeme dar. Hierzu werden Hardwareeinheiten und Softwareeinheiten nachgebildet und somit virtuell repliziert. In bestehenden 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 vorliegenden Erfindung darin, dass dedizierte Softwareeinheiten oder Softwaremodule in ihrer Laufzeit verändert werden können. Insbesondere kann die Performanz der Hardwareeinheiten angepasst werden. Gerade dies kann aber auf einer unterschiedlichen Hardwareausstattung des Zielsystems zu Synchronisationsfehlern führen.
Erfindungsgemäß kann eine bessere und vor allem realitätsgetreuere Testabdeckung gewährleistet werden. Erfindungsgemäß kann zur Analyse des Synchronisationsverhaltens nicht nur die Reihenfolge geändert werden, sondern insgesamt kann das Ablaufverhalten, 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 gewä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 vorliegende Erfindung durch die Virtualisierung der Umgebung eine Automatisierung des Testens und ein Testen unterschiedlichster Systeme. Daraus resultieren erhebliche Zeit- und Kostenersparnisse sowie eine höhere Sicherheit und eine Fehlerreduzierung 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 Programmiersprachen 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önnen zwar Synchronisationsfehler aufgefunden werden, das zu testende System muss allerdings als Formel oder Systembeschreibung 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. Damit 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 Programmierwerkzeugen, beispielsweise die Werkzeuge ”FindBug” [1] und ”RacerX” [5], die nach statischen Mustern im Softwarecode sucht. Neben der Fehleranfälligkeit der sogenannte ”False Positives”, das heißt aufgefundene Fehler, die tatsächlich keine 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 Wiederverwendung 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ömmlicherweise 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 Programmiersprache implementiert vorliegt, weil erfindungsgemäß empirisch getestet wird. Ein weiterer Vorteil liegt darin, dass keine sogenannten ”False Positives” gefunden werden.
Weiter werden im Folgenden die erfindungsgemäßen Vorteile gegenüber einer dynamischen Analyse durch Ausführen potenziell möglicher Thread-Interleavings aufgezeigt.
Ein Beispiel für eine dynamische Analyse durch Ausführen potenziell 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 einigen nicht aufgefundenen Fehlern führen kann. Ein weiteres Problem des Tools ”Chess” liegt in echter Hardwareparallelität. Es ist wahrscheinlich, dass bei einer echten Parallelität im Gegensatz zu einer Pseudoparallelität Fehler auftreten, 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, mittels dem Data Races gefunden werden können. Hierbei wird eine virtuelle Maschine instrumentiert. Die Aktionen des Programms werden protokolliert und potenzielle Data Races werden referiert. 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 Zielsystemen 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 einen 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 einen einstellbaren Startzeitpunkt und/oder ein Variieren des zumindest einen einstellbaren Endzeitpunktes.
Beispielsweise wird der Ausführungszeitpunkt der Softwareeinheiten 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 bezeichnet.
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 implementiert. 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 Hardwareeinheiten, beispielsweise virtualisierte Hardwarekomponenten, derart 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 Conditions und Synchronisationsfehler. Diese Fehler können herkömmlicherweise nur zufällig in einem herkömmlichen Testprozess 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 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 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 Ausfü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 dedizierten Art und Weise zumindest eine zu untersuchende Synchronisations-Maßnahme unterbunden, um insbesondere Race Conditions 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 Prolongieren selbst wird durch das erfindungsgemäße Testmittel durchgeführt. Das erfindungsgemäße Testmittel umfasst insbesondere 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 prolongiert 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 aufgefunden 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 schematischen Figuren angegebenen Ausführungsbeispiele näher erläutert. Es zeigen:
1 ein schematisches Ablaufdiagramm eines ersten Ausführungsbeispiels eines Verfahrens zum Testen eines Systems mit einer Mehrzahl von parallel ausführbaren Softwareeinheiten;
2 ein schematisches Ablaufdiagramm eines zweiten Ausführungsbeispiels eines Verfahrens zum Testen eines Systems mit einer Mehrzahl von parallel ausführbaren Softwareeinheiten;
3 ein schematisches Ablaufdiagramm eines dritten Ausführungsbeispiels eines Verfahrens zum Testen eines Systems mit einer Mehrzahl von parallel ausführbaren Softwareeinheiten; und
4 ein schematisches Blockschaltbild eines Ausführungsbeispiels einer Vorrichtung zum Testen eines Systems mit einer Mehrzahl von parallel ausführbaren Softwareeinheiten.
In allen Figuren sind gleiche bzw. funktionsgleiche Mittel und Einrichtungen – sofern nichts anderes angegeben – mit denselben Bezugszeichen versehen.
1 zeigt ein schematisches Ablaufdiagramm eines ersten Ausführungsbeispiels eines Verfahrens zum Testen eines Systems 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 Softwareeinheit hat eine jeweilige programmierte oder codierte Laufzeitdauer der Ausführung. Weiter umfasst die jeweilige Softwareeinheit beispielsweise ein Programm und Daten.
Das erste Ausführungsbeispiel des erfindungsgemäßen Verfahrens gemäß 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 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 Detektion von Synchronisationsfehlern des Systems.
Vorzugsweise ist das Variieren der zumindest einen einstellbaren 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.
2 zeigt ein schematisches Ablaufdiagramm eines zweiten Ausführungsbeispiels eines Verfahrens zum Testen eines Systems 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 2 hat die Verfahrensschritte 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 Ausführung und durch einen Endzeitpunkt der Ausführung ausgebildet.
Dabei wird die vorbestimmte Laufzeitdauer zumindest einer Softwareeinheit in eine einstellbare Laufzeiteinheit geändert. Zusätzlich wird vorzugsweise der vorbestimmte Startzeitpunkt zumindest einer Softwareeinheit in einen einstellbaren Startzeitpunkt geändert. Zusätzlich oder alternativ wird auch der vorbestimmte Endzeitpunkt zumindest einer Softwareeinheit 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 abzuarbeiten. 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 Laufzeiteigenschaften der nachgebildeten Hardwareeinheit, durch welche das jeweilige Softwaremittel zum Ausführungszeitpunkt des Softwaremittels abgearbeitet wird, einstellbar ist. Die jeweilige Hardwareeinheit ist beispielsweise als Computer, Mikroprozessor, Einrichtung oder auch als Teil eines Computersystems ausgebildet.
Verfahrensschritt 202:
Ein Testmittel 3 (siehe 3) wird zum Validieren des Systems und zum Einstellen der einstellbaren Laufzeiteigenschaften bereitgestellt.
Verfahrensschritt 203:
Das System wird zur Bereitstellung von Testergebnisdaten getestet. Dabei wird eine vorbestimmbare Anzahl von vorbestimmten 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 Testergebnisdaten zur Detektion von unnötigen Synchronisationsmaßnahmen validiert werden.
In 3 ist ein schematisches Ablaufdiagramm eines dritten Ausführungsbeispiels eines Verfahrens zum Testen eine Systems mit einer Mehrzahl von parallel ausführbaren Softwareeinheiten dargestellt.
Das dritte Ausführungsbeispiel basiert auf dem ersten Ausführungsbeispiel gemäß 1 und umfasst sämtliche mit Bezug zu 1 dargestellten Merkmale. Das dritte Ausführungsbeispiel der 3 hat die Verfahrensschritte 301 bis 303:
Verfahrensschritt 301:
Eine Mehrzahl von programmierten oder vorbestimmten Laufzeitdauern einer Mehrzahl von Softwareeinheiten wird zur Bereitstellung von jeweils einstellbaren Laufzeitdauern geändert.
Verfahrensschritt 302:
Ein Testmittel 3 (siehe 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 durchgeführt, wobei das Testen ein Variieren der Mehrzahl der einstellbaren Laufzeitdauern der Mehrzahl der Softwareeinheiten zur Detektion von Synchronisationsfehlern des Systems beinhaltet.
4 zeigt ein schematisches Blockschaltbild eines Ausführungsbeispiels 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 programmierte Laufzeitdauer der Ausführung.
Die Vorrichtung hat zumindest ein Änderungsmittel 2 und ein Testmittel 3.
Das Änderungsmittel 2 ist dazu eingerichtet, eine programmierte oder vorbestimmte Laufzeitdauer zumindest einer Softwareeinheit in eine einstellbare Laufzeitdauer zu ändern. Damit stellt das Änderungsmittel 2 ausgangsseitig zumindest eine geänderte Softwareeinheit 4 bereit.
Das Testmittel 3 ist dazu eingerichtet, das System zur Bereitstellung 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 bevorzugten Ausführungsbeispiele beschrieben wurde, ist sie darauf nicht beschränkt, sondern auf vielfältige Art und Weise modifizierbar.
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.130.-ISSN 0740-7459
[2] Bacon, David F.; Strom, Robert E.; Tarafdar, Ashis: Guava: A dialect of Java without data races. In: In Object-Oriented Programming, Systems, Languages, and Applications (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 17th ACM SIGPLAN conference on Objectoriented programming, systems, languages, and applications Bd. 37. New York, NY, USA: ACM Press, November 2002.-ISBN 1581134711, 211–230
[4] Choi, Jong-Dek; Lee, Keunwoo; loginov, Alexey; O'Callahan; Robert; Sarkar, Vivek; Sridharan, Manu: Efficient and precise datarace detection for multithreaded objectoriented 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.945468.-DOIhttp://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 Conference. 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 an 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, Gérard; 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 Letters an Programming Languages and Systems 1 (1992), S. 74–88.
[11] Stoller, Scott D.: Testing Concurrent Java Programs using Randomized Scheduling. In: Proc. Second Workshop an Runtime Verification (RV) Bd. 70(4), Elsevier, Juli 2002 (Electronic Notes in Theoretical Computer Science)
[12] Yourdon Edward, Larry L. C.: Structured Design: Fundamentals 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 Academic Publishers, 1987
[14] Yu, Yuan; Rodeheffer, Tom; Chef, Wei: Race Track: Efficient 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

ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Nicht-Patentliteratur

IEEE Standard 610 [0018]

Claims

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 Laufzeitdauer der Ausführung haben, mit den Schritten: a) Ändern der vorbestimmten Laufzeitdauer zumindest einer Softwareeinheit in eine einstellbare Laufzeitdauer (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ändert wird und dass der vorbestimmte Startzeitpunkt zumindest einer Softwareeinheit in einen einstellbaren Startzeitpunkt geändert wird und/oder dass der vorbestimmte Endzeitpunkt zumindest einer Softwareeinheit 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 Laufzeiteigenschaft 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 Laufzeiteigenschaft 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 Laufzeiteigenschaften der nachgebildeten Hardwareeinheit, durch welche das jeweilige Softwaremittel zum Ausführungszeitpunkt des Softwaremittels abgearbeitet wird, einstellbar 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 vorbestimmbare 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 Testergebnisdaten zur Detektion von unnötigen Synchronisationsmaßnahmen validiert werden (203).
Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass die durch das Testen untersuchten Synchronisationsmaßnahmen bei einer positiven Validierung der bereitgestellten Testergebnisdaten als unnötige Synchronisationsmaß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).
Verfahren nach Anspruch 11, dadurch gekennzeichnet, dass das Testen ein Variieren der Mehrzahl der einstellbaren Laufzeitdauern der Mehrzahl der Softwareeinheiten beinhaltet (303).
Computerprogrammprodukt, welches auf einer programmgesteuerten Einrichtung die Durchführung eines Verfahrens nach einem der Ansprüche 1–12 veranlasst.
Vorrichtung (1) zum Testen eines Systems mit zumindest einer Mehrzahl von parallel ausführbaren Softwareeinheiten, welche zur Ausführung eines Threads und zur Bereitstellung eines gemeinsamen Ergebnisses eingerichtet sind und welche eine jeweilige programmierte Laufzeitdauer der Ausführung haben, mit: a) einem Änderungsmittel (2) zum Ändern einer vorbestimmten 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.