DE19959157C2 - Verbessertes Funktionstesten durch das Filtern von groben Mutationen - Google Patents

Verbessertes Funktionstesten durch das Filtern von groben Mutationen

Info

Publication number
DE19959157C2
DE19959157C2 DE19959157A DE19959157A DE19959157C2 DE 19959157 C2 DE19959157 C2 DE 19959157C2 DE 19959157 A DE19959157 A DE 19959157A DE 19959157 A DE19959157 A DE 19959157A DE 19959157 C2 DE19959157 C2 DE 19959157C2
Authority
DE
Germany
Prior art keywords
mutation
syntactic
computer program
source code
function
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
DE19959157A
Other languages
English (en)
Other versions
DE19959157A1 (de
Inventor
Alan Wiemann
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hewlett Packard Development Co LP
Original Assignee
Hewlett Packard Co
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hewlett Packard Co filed Critical Hewlett Packard Co
Publication of DE19959157A1 publication Critical patent/DE19959157A1/de
Application granted granted Critical
Publication of DE19959157C2 publication Critical patent/DE19959157C2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3668Software testing
    • G06F11/3672Test management
    • G06F11/3688Test management for test execution, e.g. scheduling of test suites

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)
  • Stored Programmes (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Description

Die vorliegende Erfindung bezieht sich allgemein auf das Überprüfen der Funktionsweise von Computerprogrammen und insbesondere auf eine Vorrichtung und ein Verfahren zum Funktionstesten eines Computerprogramms, um zu bestimmen, ob eine Testreihe das Computerprogramm korrekt testet, und um eine Wahrscheinlichkeit dafür zu bestimmen, daß in dem Com­ puterprogramm immer noch Funktionsprogrammfehler (functional bugs) existieren.
Da die Größe und Komplexität von Computerprogrammen zunimmt, gibt es typischerweise eine entsprechende Zunahme der Anzahl von syntaktischen Fehlern, die in den Quellcode dieser Pro­ gramme eingefügt werden. Zusätzlich machen die zunehmende Größe und Komplexität heutiger Computerprogramme eine Erfas­ sung und Abtrennung dieser syntaktischen Fehler zu einer viel schwierigeren Aufgabe.
Die IEEE-Standard-Definition eines Fehlers ist ein Fehlver­ sagen (mistake), das durch einen Entwickler erzeugt wird. Ein Fehler kann zu einer oder mehreren Softwaremutationen führen (die ferner als Defekte (faults) bekannt sind). Mu­ tationen sind in dem Quellcode eines Computerprogramms po­ sitioniert. Eine Mutation ist ein Unterschied zwischen einem unkorrekten Programm und einem entsprechenden korrekten Pro­ gramm. Die Mutation kann in einer Anweisung positioniert sein oder kann textmäßig in mehreren Positionen in dem Com­ puterprogramm verteilt sein. Dementsprechend kann die Muta­ tion auf viele Weisen behebbar sein, wobei jede zu einem korrekten aber unterschiedlichen Programm führt. Siehe dazu: Offutt A. und Hayes J., "A Semantic Model of Program Faults", Proceedings of the 1996 International Symposium on Software Testing and Analysis, Mai 1996.
Die im vorhergehende erwähnte Definition einer Mutation bezieht sich auf die syntaktische Natur einer Mutation. Falls die Mutation in das Computerprogramm eingefügt wird, ist die syntaktische Natur der Mutation durch die ent­ sprechenden Änderungen des Computerprogramms beschrieben. Falls die Mutation in dem Programm von selbst auftritt, ist die syntaktische Natur der Mutation durch die Anzahl von Änderungen beschrieben, die notwendig sind, um das Programm zu korrigieren. Beispiele von syntaktischen Charakterisie­ rungen von Mutationen umfassen das Verwenden eines nicht­ korrekten variablen Namens oder das Überprüfen, um zu er­ kennen, ob eine aufgerufene Funktion fehlschlägt. Solche Mutationen werden häufig durch Fehlverhalten der Programmie­ rer hervorgerufen, wie z. B. durch typographische Fehler.
Eine Mutation kann ferner semantisch charakterisiert sein. Jedes Computerprogramm P kann so betrachtet werden, als ob dasselbe eine Spezifikation S aufweist, die Sätze D (einen Eingangsdefinitionsbereich) und R (einen Ausgangsbereich) und eine Abbildung von D nach R definiert (D R). Eine semantische Charakterisierung einer Mutation betrachtet das fehlerhafte Computerprogramm so, als ob dasselbe eine Be­ rechnung enthält, die eine unkorrekte Ausgabe bezüglich eines gewissen Teilsatzes des Eingangsdefinitionsbereichs erzeugt. Das heißt, daß die Abbildung von Eingangswerten auf Ausgangswerte (D R) für einen gewissen Teilsatz von D unkorrekt (D R ≠ D R) ist.
Die Charakterisierung einer Mutation als "semantisch" und "syntaktisch" erweist sich als ziemlich nützlich, wenn man die Größe einer Mutation betrachtet. Für eine syntaktisch kleine Mutation kann es sein, daß ein Token oder eine An­ weisung unkorrekt ist. Für eine semantisch kleine Mutation ist das Verhalten von P bezüglich eines sehr kleinen Teil­ satzes von D unkorrekt. Eine Mutation, die syntaktisch klein ist, kann eine Mutation ergeben, die semantisch sehr groß ist, da die syntaktische Mutation willkürlich viele Eingangswerte beeinträchtigen kann. Ferner kann eine größere syntaktische Mutation von P lediglich wenige Eingangswerte beeinflussen, woraus sich eine kleine semantische Mutation ergibt. Schließlich gibt es Fälle, bei denen eine kleine semantische Mutation als kleine syntaktische Mutationen gestaltet werden kann, wobei kleine syntaktische Mutationen kleine semantische Mutationen ergeben können.
Es bestehen erhebliche Verhaltensunterschiede zwischen syn­ taktisch-kleinen/semantisch-großen Mutationen und syntak­ tisch-kleinen/semantisch-kleinen Mutationen. Syntaktisch- kleine/semantisch-große Mutationen sind während des Funk­ tionstestens und des Überprüfungsprozesses von geringem Wert. Dies wird durch die Tatsache deutlich, daß syntak­ tisch-kleine/semantisch-große Mutationen ohne weiteres durch nahezu jeden Testfall erfaßt werden, der die mutationsbehaf­ tete Anweisung erreicht. Diese syntaktisch-kleinen/seman­ tisch-großen Mutationen sind ferner einem hohen Grad von Überlappung ausgesetzt. Das heißt, daß ein Testen/Überprü­ fungs-Testfall, der eine syntaktisch-kleine/semantisch-große Mutation beseitigt, beinahe immer viele weitere syn­ taktisch-kleine/semantisch-große Mutationen beseitigen wird. Im Unterschied dazu sind die feinen, syntaktisch-kleinen/se­ mantisch-kleinen Mutationen während eines normalen Funk­ tionstestens oder einer normalen Funktionsüberprüfung viel schwieriger zu erfassen. Folglich wird die Erfassung von diesen feinen, syntaktisch-kleinen/semantisch-kleinen Muta­ tionen zu Tests mit einer höheren Qualität führen.
Herkömmliche Softwarefunktionstest-und-Überprüfungs-Systeme haben sich auf Mutationen konzentriert, die syntaktisch klein sind, ohne die semantische Größe zu berücksichtigen. Wie es in dem vorhergehenden Absatz erwähnt wurde, sind Mutationen, die syntaktisch klein aber semantisch groß sind, durch einen sehr einfachen Satz von Testvektoren erfaßbar; sie fügen dem Funktions-Test-und-Überprüfungs-Prozeß eine Schwierigkeit hinzu, ohne den Testwert der sich ergebenden Regressionstestfälle zu erhöhen. Syntaktisch kleine Fehler (Abweichungen) weisen typischerweise eine hohe semantische Größe auf, und versagen folglich, den Wert der sich ergeben­ den Testfälle zu erhöhen.
Angesichts des im vorhergehenden Erwähnten besteht eine Not­ wendigkeit für ein System zum Erfassen und Ausrangieren von syntaktisch kleinen Fehlern mit einer hohen Semantischen Größe und zum Integrieren dieses Konzeptes in ein Funktions­ simulations-und-Überprüfungs-System, um eine Wahrschein­ lichkeit dafür zu bestimmen, daß in einem Softwareprogramm unerfaßte Funktionsprogrammfehler existieren, und ob eine Testreihe das Computerprogramm korrekt testet.
In dem Artikel von Jeffrey Voas, u. a. "Predicting how badly good software can behave" in: IEEE Software, Juli/August 1997, Seiten 73 bis 81 werden Testverfahren für Software be­ schrieben, bei denen eine Fehlereingabe und eine Fehlertole­ ranzmessung unter Verwendung von ganz seltenen Eingaben ver­ wendet wird. Hierzu werden vorsätzlich simulierte "Infektio­ nen" verwendet, welche einfach simulierte Datenzustands­ fehler sind. Diese simulierten Infektionen ermöglichen es einem Anwender zu beobachten, welchen Einfluß unterschied­ liche Arten von fehlerhaften Zuständen, von denen einige schlechte Zustände sein können, auf das Verhalten des Sy­ stems haben. Insbesondere ist zu erkennen, ob ein System nach dem Eintreten in einen schlechten Zustand in der Lage ist, sich beim Auftreten eines weiteren Ereignisses in einen korrekten Zustand zurückzubewegen, oder zumindest festzu­ stellen, daß der schlechte Zustand keine schädlichen Kon­ sequenzen für das Gesamtsystem hat.
Die Aufgabe der vorliegenden Erfindung besteht darin, eine Vorrichtung und ein Verfahren zum funktionsmäßigen Über­ prüfen eines Computerprogramms zu schaffen, um zu Bestimmen, ob eine Testfolge das Computerprogramm korrekt überüprüft.
Diese Aufgabe wird durch ein System gemäß Anspruch 1 und ein Verfahren gemäß Anspruch 17 gelöst.
Die vorliegende Erfindung liefert ein Funktionstestsystem zum funktionsmäßigen Simulieren und Überprüfen der Korrekt­ heit eines Computerprogramms. Das Funktionstestsystem der vorliegenden Erfindung umfaßt eine Mutationserzeugungs­ einrichtung zum Erzeugen von mehreren mutationsbehafteten Computerprogrammen, wobei jedes mutationsbehaftete Computer­ programm eine syntaktische Mutation aufweist. Das Funktions­ testsystem der vorliegenden Erfindung weist ferner einen er­ sten Funktionssimulator bzw. eine Funktionssimuliereinrich­ tung zum seriellen Verarbeiten jedes mutationsbehafteten Computerprogramms auf. Dieser erste Funktionssimulator iden­ tifiziert, ob die syntaktische Mutation in jedem mutations­ behafteten Computerprogramm eine grobe syntaktische Mutation ist. Falls die syntaktische Mutation tatsächlich eine grobe syntaktische Mutation ist, wird die Funktionssimulation des mutationsbehafteten Computerprogramms, das die grobe syntak­ tische Mutation enthält, beendet. Der erste Funktionssi­ mulator identifiziert dann jede syntaktische Mutation, die nicht als eine grobe Mutation identifiziert wurde, als eine feine Mutation. Das Funktionstestsystem der vorliegenden Erfindung weist ferner einen zweiten Funktionssimulator zum seriellen Verarbeiten jedes mutationsbehafteten Computerpro­ gramms mit einer feinen syntaktischen Mutation auf. Der zweite Funktionssimulator beendet die Funktionssimulation jedes mutationsbehafteten Computerprogramms, falls derselbe die feine syntaktische Mutation innerhalb einer vorbestimm­ ten Simulationsperiode erfaßt. Falls der zweite Funktionssi­ mulator jedoch die feine syntaktische Mutation innerhalb der vorbestimmten Simulationsperiode nicht erfaßt, liefert der zweite Funktionssimulator eine Anzeige dafür, daß die feine syntaktische Mutation nicht erfaßt wurde.
Bei einem Ausführungsbeispiel der vorliegenden Erfindung weist das Computerprogramm eine Mehrzahl von Quellcode­ modulen auf. Bei einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung besteht die Mehrzahl von Quellcode­ modulen aus Funktionsmodellen einer integrierten Schaltung. Die Mutationserzeugungseinrichtung identifiziert einen Satz von auswählbaren Quellcodemodulen aus der Mehrzahl von Quellcodemodulen, die Kandidaten für eine Einfügung einer syntaktischen Mutation sind. Eine syntaktische Mutation wird daraufhin in ein Element eingefügt, das aus dem Satz von auswählbaren Quellcodemodulen ausgewählt ist. Die Auswahl eines Elements aus dem Satz von auswählbaren Quellcodemo­ dulen wird auf zufällige Weise durchgeführt, oder durch ein Verteilungsschema, das die tatsächliche Verwendung der Module in dem arbeitenden Computerprogramm widerspiegelt.
Die Mutationserzeugungseinrichtung wählt eine syntaktische Mutation für eine Einfügung in einem auswählbaren Quellcode­ modul aus einem vordefinierten Satz von syntaktischen Muta­ tionstypen aus. Die Auswahl der syntaktischen Mutation wird auf zufällige Weise durchgeführt, oder durch ein Verteilungsschema, das die Wahrscheinlichkeit des Antreffens des Mutationstyps während eines normalen Betriebs des Computer­ programms widerspiegelt. Die Typen von syntaktischen Muta­ tionen, die für eine Einfügung ausgewählt werden, umfassen folgende Typen, sind aber nicht auf dieselben begrenzt: logische Negationsfehler, Auslassungen logischer Ausdrücke, Auslassungen logischer Faktoren, unkorrekte logische Aus­ drücke, unkorrekte logische Faktoren, unkorrekte numerische Werte und Fallauslassungen.
Auf das Abschließen der Funktionssimulation des Computer­ programms hin liefert die vorliegende Erfindung einem Be­ nutzer eine statistisch hergeleitete Wahrscheinlichkeit dafür, daß immer noch unerfaßte tatsächliche Mutationen in dem Computerprogramm vorhanden sind.
Die vorliegende Erfindung liefert ferner ein Verfahren zum funktionsmäßigen Simulieren und Überprüfen der Korrektheit eines Computerprogramms. Das Verfahren beginnt mit dem Er­ zeugen eines mutationsbehafteten Computerprogramms, das eine syntaktische Mutation aufweist. Das Verfahren vorverarbeitet als nächstes das mutationsbehaftete Computerprogramm, um die syntaktische Mutation in dem mutationsbehafteten Computer­ programm als entweder eine feine oder eine grobe syntak­ tische Mutation zu identifizieren. Falls das mutationsbehaf­ tete Computerprogramm eine grobe syntaktische Mutation auf­ weist, wird die Funktionssimulation des mutationsbehafteten Computerprogramms beendet, wobei ein weiteres mutationsbe­ haftetes Computerprogramm erzeugt wird, wie es im vorherge­ henden beschrieben wurde. Falls das mutationsbehaftete Com­ puterprogramm eine feine syntaktische Mutation enthält, wird daraufhin in einem Versuch, die feine syntaktische Mutation in dem mutationsbehafteten Computerprogramm innerhalb einer vorbestimmten Simulationsperiode zu erfassen, das mutations­ behaftete Computerprogramm simuliert. Falls die feine syn­ taktische Mutation innerhalb einer vorbestimmten Simula­ tionsperiode erfaßt wird, wird die Funktionssimulation des mutationsbehafteten Computerprogramms beendet, wobei ein weiteres mutationsbehaftetes Computerprogramm erzeugt wird, wie es im vorhergehenden beschrieben wurde. Falls jedoch innerhalb einer vorbestimmten Simulationsperiode die feine syntaktische Mutation nicht erfaßt wird, liefert die vor­ liegende Erfindung eine Anzeige dafür, daß die feine syntak­ tische Mutation nicht erfaßt wurde.
Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung werden nachfolgend bezugnehmend auf die begleitenden Zeich­ nungen näher erläutert. Es zeigen:
Fig. 1 ein Funktions-Block-und-Fluß-Diagramm einer Funk­ tionstest-und-Überprüfungs-Umgebung gemäß der vor­ liegenden Erfindung;
Fig. 2 ein Prozeßflußdiagramm eines Funktionstest-und- Überprüfungs-Systems gemäß der vorliegenden Erfin­ dung;
Fig. 3 ein veranschaulichendes Beispiel eines Computer­ programms mit einem Quellcodemodul, einem Satz von Eingangswerten und einem Satz von Ausgangswerten;
Fig. 4 drei vereinfachte Implementierungen des Quellcode­ moduls, das in Fig. 3 dargestellt ist, wobei die erste Implementierung ein korrektes Quellcodeseg­ ment enthält, die zweite Implementierung eine grobe Mutation in das korrekte Quellcodesegment ein­ bringt, und die dritte Implementierung eine feine Mutation in das korrekte Quellcodesegment ein­ bringt, und wobei alle drei Implementierungen einer ersten Funktionssimulation (Feinheitsüberprüfung) unterzogen werden;
Fig. 5 die dritte Implementierung des Quellcodemoduls, das in Fig. 4 dargestellt ist, wobei die dritte Imple­ mentierung eine feine Mutation in das korrekte Quellcodesegment einbringt, und wobei die dritte Implementierung einer zweiten Funktionssimulation (vollständigen Regressionsüberprüfung) unterzogen wird, die in der Lage ist, die feine Mutation zu erfassen;
Fig. 6 die dritte Implementierung des Quellcodemoduls, das in Fig. 4 dargestellt ist, wobei die dritte Imple­ mentierung eine feine Mutation in das korrekte Quellcodesegment einbringt, und wobei die dritte Implementierung einer zweiten Funktionssimulation (vollständigen Regressionsüberprüfung) unterzogen wird, die nicht in der Lage ist, die feine Mutation zu erfassen; und
Fig. 7 ein computerlesbares Medium, das ein Funktionstest­ system gemäß der vorliegenden Erfindung unter­ bringt.
In der folgenden detaillierten Beschreibung der bevorzugten Ausführungsbeispiele wird Bezug auf die begleitenden Zeich­ nungen genommen, die einen Teil derselben bilden, und in denen exemplarisch spezifische Ausführungsbeispiele gezeigt sind, in denen die Erfindung ausgeführt ist. Es wird darauf hingewiesen, daß andere Ausführungsbeispiele verwendet wer­ den können, und daß strukturelle oder logische Änderungen durchgeführt werden können, ohne den Schutzbereich der vor­ liegenden Erfindung zu verlassen. Die folgende detaillierte Beschreibung ist folglich nicht in einem begrenzenden Sinne zu verstehen, wobei der Schutzbereich der vorliegenden Er­ findung durch die anhängigen Patentansprüche definiert ist.
Fig. 1 ist ein Block-Und-Flußdiagramm einer Funktionstest- und-Überprüfungs-Umgebung 20, die gemäß der vorliegenden Erfindung ein Funktionstestsystem 22 zum Simulieren und Überprüfen der Korrektheit eines Computerprogramms aufweist. Das Funktionstestsystem 22 weist eine Mutationserzeugungs­ einrichtung 24, einen ersten Funktionssimulator 26 und einen zweiten Funktionssimulator 28 auf.
Die Funktionstest-und-Überprüfungs-Umgebung 20 weist ferner ein Computerprogramm 30, das einem Funktionstest durch das Funktionstestsystem 22 unterzogen wird, und einen vordefi­ nierten Satz von syntaktischen Mutationstypen 40 auf, die in das Computerprogramm 30 selektiv eingefügt werden können, bevor das Computerprogramm einem Funktionstesten unterzogen wird. In dem Zusammenhang der vorliegenden Erfindung ist das Computerprogramm 30 ein Satz von Anweisungen, Befehlen und/oder Daten, die direkt oder indirekt in einem Computer verwendet werden sollen, um ein bestimmtes Ergebnis hervor­ zurufen. Das Computerprogramm 30 kann in der Form von Soft­ ware, Firmware oder programmierbarer Hardware vorliegen. Ausführungsbeispiele des Computerprogramms 30 in dem Zusam­ menhang der vorliegenden Erfindung umfassen Modelle von Pro­ zessen und von physischen Vorrichtungen, wie z. B. inte­ grierten Schaltungen, sind aber nicht auf dieselben be­ grenzt. Das Computerprogramm 30 weist ein oder mehrere Quellcodemodule 32 und 34 auf. Eine erste allgemeine Klassi­ fizierungsgruppe 36 weist Quellcodemodule 32 auf, die keine Kandidaten für eine Einfügung einer syntaktischen Mutation sind. Eine zweite allgemeine Klassifizierungsgruppe 38 weist Quellcodemodule 34 auf, die Kandidaten für eine Einfügung einer syntaktischen Mutation sind. Eine Modulauswähleinrich­ tung 56 wählt ein Quellcodemodul 34 aus der Gruppe 38 aus, die Kandidaten für eine Einfügung einer syntaktischen Muta­ tion sind, und leitet das ausgewählte Modul an die Muta­ tionserzeugungseinrichtung 24 weiter. Eine Auswähleinrich­ tung 58 für eine syntaktische Mutation wählt einen syntak­ tischen Mutationstyp aus einem vordefinierten Satz von syn­ taktischen Mutationstypen 40 aus und leitet den ausgewählten syntaktischen Mutationstyp an die Mutationserzeugungsein­ richtung 24 weiter. Exemplarische Beispiele von syntak­ tischen Mutationstypen, die in einem vordefinierten Satz von syntaktischen Mutationstypen 40 vorgefunden werden, umfas­ sen: logische Negationsfehler 42; Auslassungen logischer Faktoren 44; unkorrekte logische Faktoren 46; Auslassungen 48 von logischen Ausdrücken; unkorrekte logische Ausdrücke 50; unkorrekte numerische Werte 52; Fallauslassungen 54 und andere derartige syntaktische Mutationstypen.
Nach dem Empfangen eines ausgewählten Quellcodemoduls 60 und eines ausgewählten Mutationstyps fügt die Mutationserzeu­ gungseinrichtung 24 eine tatsächliche Mutation des ausge­ wählten Typs von Mutation in das Quellcodemodul 60 ein, und kompiliert das Computerprogramm mit dem neu erzeugten muta­ tionsbehafteten Quellcodemodul neu, derart, daß ein neues mutationsbehaftetes Computerprogramm 25 erzeugt wird. In einigen Fällen ist die Mutationserzeugungseinrichtung nicht in der Lage, eine tatsächliche Mutation des ausgewählten Typs von Mutation in das ausgewählte Quellcodemodul 60 ein­ zufügen, da der Quellcode in dem ausgewählten Modul die ausgewählte Mutation nicht unterstützt. In diesem Fall wer­ den ein neues Quellcodemodul und ein neuer Mutationstyp ausgewählt und an die Mutationserzeugungseinrichtung 24 wei­ tergeleitet.
Das resultierende mutationsbehaftete Computerprogramm 25 wird durch einen ersten Funktionssimulator 26 verarbeitet, der eine Feinheitsüberprüfung bezüglich des mutationsbe­ hafteten Computerprogramms durchführt. Bei einem Ausfüh­ rungsbeispiel ist die Feinheitsüberprüfung als eine Reihe von sehr grundlegenden Tests implementiert, die die Basis­ funktionalität des mutationsbehafteten Computerprogramms 25 ausüben. Der Satz von Basistests ist basierend auf der Kenntnis aufgebaut, die während des Entwicklungsprozesses durch gewöhnliches Testen des Computerprogramms erhalten wird. Falls die Mutation, die in das Computerprogramm einge­ bracht wird, so schwerwiegend ist, daß die Basisfunktions­ weise des Computerprogramms gestört wird, wird die Mutation als eine grobe Mutation klassifiziert, wie es bei 66 darge­ stellt ist. Eine solche grobe Mutation ist typischerweise eine Mutation mit einer geringen syntaktischen Größe aber einer hohen semantischen Größe. Falls die Mutation als eine grobe Mutation klassifiziert wird, wird kein weiteres Funktionstesten an dem mutationsbehafteten Computerprogramm durchgeführt, da die Mutation bereits durch die Basisfein­ heitsüberprüfung erfolgreich identifiziert ist, die durch den ersten Funktionssimulator 26 durchgeführt wird, wobei ein vollständiges Regressionstesten bezüglich grober Muta­ tionen im wesentlichen keinen Vorteil für das Gesamtfunk­ tionstestergebnis liefert. Falls der erste Funktionssimula­ tor 26 das mutationsbehaftete Computerprogramm als ein eine grobe Mutation enthaltendes Programm identifiziert, wird die Steuerung folglich über einen Weg 68 an die Mutationserzeu­ gungseinrichtung 24 zurückgegeben. Die Modulauswähleinrich­ tung 56 wählt ein neues Quellcodemodul 34 aus, die Auswähl­ einrichtung 58 für eine syntaktische Mutation wählt einen neuen syntaktischen Mutationstyp aus, und die Mutationser­ zeugungseinrichtung 24 erzeugt ein neues mutationsbehaftetes Computerprogramm.
Falls der erste Funktionssimulator 26 das mutationsbehaftete Computerprogramm nicht als ein eine grobe Mutation enthal­ tendes Programm identifiziert, wird das mutationsbehaftete Computerprogramm 25 als ein eine feine Mutation enthaltendes Programm identifiziert. Das mutationsbehaftete Computerpro­ gramm, das die feine Mutation enthält, wird über einen Weg 70 an einen zweiten Funktionssimulator 28 weitergeleitet. Der zweite Funktionssimulator 28 führt einen weit aus voll­ ständigeren und zeitaufwendigeren Funktionstest als denje­ nigen durch, der durch den Funktionssimulator 26 durch­ geführt wird. Der zweite Funktionssimulator 28 führt einen vollständigen Regressionstest, der eine Reihe von Test­ vektoren 64 verwendet, bezüglich des mutationsbehafteten Computerprogramms durch.
Falls die feine Mutation, die sich in dem mutationsbehaf­ teten Computerprogramm befindet, durch den zweiten Funk­ tionssimulator 28 innerhalb eines vorbestimmten Testmaßes gefunden wird, wie es bei 72 angezeigt ist, wird das muta­ tionsbehaftete Computerprogramm als ein eine feine, erfaß­ bare Mutation enthaltendes Programm identifiziert, wobei die Steuerung über einen Weg 74 an die Mutationserzeugungsein­ richtung 24 zurückgegeben wird. Die Modulauswähleinrichtung 56 wählt ein neues Quellcodemodul 34 aus, die Auswählein­ richtung 58 für eine syntaktische Mutation wählt einen neuen syntaktischen Mutationstyp aus, und die Mutationserzeugungs­ einrichtung 24 erzeugt ein neues mutationsbehaftetes Compu­ terprogramm. Falls jedoch die feine Mutation, die sich in dem mutationsbehafteten Computerprogramm befindet, durch den zweiten Funktionssimulator 28 innerhalb eines vorbestimmten Testmaßes nicht erfaßt wird, wie es bei 72 angezeigt ist, wird das mutationsbehaftete Computerprogramm als ein eine feine, nicht erfaßbare Mutation enthaltendes Programm iden­ tifiziert, wobei eine Anzeige der Erfassung des feinen, nicht erfaßbaren Fehlers geliefert wird, wie es bei 78 angezeigt ist. An diesem Punkt wird die Funktionstestreihe 64, die durch den zweiten Funktionssimulator 28 verwendet wird, verbessert, um den feinen, nicht erfaßbaren Fehler, der sich in dem gegenwärtigen mutationsbehafteten Computer­ programm befindet, zu erfassen. Nachdem die Testreihe ver­ bessert worden ist, wird die Steuerung über einen Weg 82 an die Mutationserzeugungseinrichtung 24 zurückgegeben. Die Modulauswähleinrichtung 56 wählt ein neues Quellcodemodul 34, die Auswähleinrichtung 58 für eine syntaktische Mutation wählt einen neuen syntaktischen Mutationstyp, und die Muta­ tionserzeugungseinrichtung 24 erzeugt ein neues mutations­ behaftetes Computerprogramm.
Fig. 2 ist ein Prozeßflußdiagramm, das die Funktionsweise des Funktionstestsystems 22 darstellt, das in der Funktions­ test-und-Überprüfungs-Umgebung 20 von Fig. 1 gemäß der vor­ liegenden Erfindung arbeitet. Der Funktionstest-und-Überprü­ fungs-Prozeß beginnt mit dem Etikettieren von auswählbaren Quellcodemodulen, die in dem Computerprogramm 30 vorgefunden werden, als Kandidaten für eine Einfügung einer Mutation, wie es bei Block 101 angezeigt ist. In einigen Fällen ist eine Einfügung einer Mutation in einem Quellcodemodul nicht wünschenswert oder sogar unmöglich. Einige Quellcodemodule können beispielsweise durch keinen Typ des vordefinierten Satzes von Mutationstypen 40 mutiert (mit einer Mutation behaftet) werden, da kein Typ des vordefinierten Satzes von Mutationstypen auf den Quellcode anwendbar ist, der in dem Quellcodemodul enthalten ist. Bei einem Ausführungsbeispiel werden die Steuerungsquellcodemodule in einem Computerpro­ gramm als auswählbar für eine Mutation etikettiert, während Datenquellcodemodule als nicht-auswählbar etikettiert wer­ den. Folglich werden bei diesem Ausführungsbeispiel bei Block 101 die Quellcodemodule des Computerprogramms in eine erste Gruppe von auswählbaren Quellcodemodulen 38 für eine Einfügung der Mutation und eine zweite Gruppe von nicht- auswählbaren Quellcodemodulen 36 für die Einfügung der Mu­ tation unterteilt.
Nachdem eine Gruppe von Quellcodemodulen, die für eine Ein­ fügung einer Mutation auswählbar sind, identifiziert worden sind, wie es bei Block 101 angezeigt ist, wird ein einzelnes Quellcodemodul aus der Gruppe ausgewählt, wie es bei Block 102 angezeigt ist. Bei einem Ausführungsbeispiel der vorlie­ genden Erfindung wird das Quellcodemodul, das aus der Gruppe von auswählbaren Modulen ausgewählt wird, auf zufällige Wei­ se ausgewählt. Bei einem alternativen Ausführungsbeispiel der vorliegenden Erfindung findet die Auswahl eines Quell­ codemoduls aus der Gruppe von auswählbaren Modulen gemäß einem gegebenen Verteilungsschema statt, wobei das Vertei­ lungsschema die tatsächlichen Betriebsbedingungen des Com­ puterprogramms widerspiegelt. Falls folglich während eines tatsächlichen Betriebs des Computerprogramms 50% der Ausfüh­ rungszeit des Programms in dem Modul "A" aufgewendet wird, 25% der Ausführungszeit des Programms in dem Modul "B" auf­ gewendet wird, und 25% der Ausführungszeit in dem Modul "C" aufgewendet wird, wird die Auswahl der Module für eine Ein­ fügung einer Mutation derart vorgespannt, daß das Modul "A" in etwa doppelt so häufig wie die Module "B" und "C" ausge­ wählt wird.
Auf das Abschließen der Auswahl eines Quellcodemoduls aus den auswählbaren Quellcodemodulen hin, wie es bei Block 102 angezeigt ist, wird ein einzelner Mutationstyp aus einer definierten Gruppe von Mutationstypen ausgewählt, wie es bei Block 104 angezeigt ist. Bei einem Ausführungsbeispiel der vorliegenden Erfindung wird der Mutationstyp, der aus der Gruppe von Mutationstypen ausgewählt wird, auf zufällige Weise ausgewählt. Bei einem alternativen Ausführungsbeispiel der vorliegenden Erfindung tritt der Mutationstyp, der aus der Gruppe von Mutationstypen ausgewählt wird, gemäß einem gegebenen Verteilungsschema auf, wobei das Verteilungsschema die tatsächlichen Betriebsbedingungen des Computerprogramms widerspiegelt. Falls folglich während des vorhergehenden Testens des Computerprogramms 50% der erfaßten Mutationen von dem Typ "Auslassungen eines logischen Ausdrucks" waren, 25% der erfaßten Mutationen von dem Typ "logischer Nega­ tionsfehler" waren, und 25% der erfaßten Mutationen "Fall­ auslassungen" waren, wird die Auswahl von Mutationstypen für eine Einfügung in dem Quellcodemodul derart vorgespannt, daß der Mutationstyp "Auslassungen von logischen Ausdrücken" in etwa doppelt so häufig wie die Mutationstypen "logischer Negationsfehler" und "Fallauslassungen" ausgewählt wird.
Nachdem der Mutationstyp aus einer definierten Gruppe von Mutationstypen ausgewählt worden ist, wie es bei Block 104 angezeigt ist, wird eine Mutation des ausgewählten Muta­ tionstyps in das ausgewählte Quellcodemodul eingefügt, wie es bei Block 106 angezeigt ist, wodurch ein mutationsbe­ haftetes Quellcodemodul erzeugt wird. Als nächstes wird das mutationsbehaftete Quellcodemodul in das Computerprogramm eingefügt, wie es bei Block 108 angezeigt ist. Das Computer­ programm, das das mutationsbehaftete Quellcodemodul enthält, wird daraufhin kompiliert, wie es bei Block 110 angezeigt ist, wodurch ein mutationsbehaftetes Computerprogramm er­ zeugt wird.
Das mutationsbehaftete Computerprogramm wird als nächstes mit dem ersten Funktionssimulator 26 simuliert und über­ prüft, wie es bei Block 112 angezeigt wird. Wie es im vor­ hergehenden beschrieben wurde, führt der erste Funktionssimulator 26 eine Feinheitsüberprüfung bezüglich des muta­ tionsbehafteten Computerprogramms durch. Bei einem Aus­ führungsbeispiel ist die Feinheitsüberprüfung als eine minimale Reihe von Tests implementiert, die die Basisfunk­ tionsweise des mutationsbehafteten Computerprogramms aus­ führt. Falls eine beliebige der ausgeführten Basisopera­ tionen des mutationsbehafteten Computerprogramms durch die eingefügte Mutation gestört wird, identifiziert der erste Funktionssimulator 26 die Mutation als grob (z. B. eine kleine syntaktische Veränderung, eine große semantische Veränderung), wie es bei Block 114 angezeigt ist. An dieser Stelle wird keine weitere Funktionssimulation durchgeführt, wobei die Prozeßsteuerung an den Block 102 zurückgegeben wird, wo ein neues Quellcodemodul und ein neuer Mutationstyp ausgewählt werden. Folglich führt der erste Funktionssimula­ tor die Feinheitsüberprüfung durch, um die groben Mutationen aus dem weiteren Testen schnell herauszufiltern, da eine weitere Simulation und Überprüfung der groben Mutationen keine weiteren Einsichten liefert. In vielen Fällen erzeugt die überwiegende Mehrheit von kleinen syntaktischen Muta­ tionen, die in die Quellcodemodule der Computerprogramme eingebracht werden, große semantische Veränderungen, und werden folglich als grob klassifiziert. Durch schnelles Identifizieren und Herausfiltern dieses großen Prozentsatzes von groben Mutationen wird die Effizienz des Funktionstest­ prozesses sehr verbessert.
Falls die syntaktische Mutation innerhalb des Computer­ programms durch den ersten Funktionssimulator 26 als fein identifiziert wird, wird das mutationsbehaftete Computer­ programm einer vollständigeren und zeitaufwendigeren zweiten Funktionssimulation unterzogen, die durch den zweiten Funk­ tionssimulator 28 durchgeführt wird, wie es bei Block 120 angezeigt ist. Der zweite Funktionssimulator 28 führt einen vollständigen Regressionstest durch, um die feine Mutation in dem mutationsbehafteten Computerprogramm zu erfassen. Falls der zweite Funktionssimulator 28 die feine Mutation innerhalb eines vorbestimmten Testmaßes erfaßt, wie es bei Block 126 angezeigt ist, wird keine weitere Funktionssimu­ lation durchgeführt, wobei die Prozeßsteuerung über einen Weg 128 an den Block 102 zurückgegeben wird, wo ein neues Quellcodemodul und ein neuer Mutationstyp ausgewählt werden. Falls jedoch der zweite Funktionssimulator 28 die feine Mutation innerhalb eines vorbestimmten Testmaßes nicht er­ faßt, wird ein Funktionsabdeckungsmangel in der Testreihe signalisiert und ein Hinweis auf den Funktionsabdeckungs­ mangel geliefert, wie es bei Block 132 angezeigt ist. An dieser Stelle wird die Funktionsüberprüfungstestreihe ver­ bessert, um den Funktionsabdeckungsmangel zu beheben, wie es bei Block 122 angezeigt ist. Bei einem Ausführungsbeispiel wird die Testreihe manuell durch einen Überprüfungstechniker verbessert. Bei einem weiteren Ausführungsbeispiel ist der Prozeß des Verbesserns der Testreihe durch die Verwendung eines oder mehrerer Computerprogramme automatisiert.
Nachdem die Funktionsüberprüfungstestreihe verbessert worden ist, um die feine Mutation zu erfassen, wird die Prozeßsteu­ erung über einen Weg 136 an den Block 102 zurückgegeben, wo ein neues Quellcodemodul und ein neuer Mutationstyp ausge­ wählt werden.
Fig. 3 ist ein exemplarisches Beispiel eines Computerpro­ gramms 150 mit einem einzigen Quellcodemodul 152, einem Satz von Eingangswerten 154 und einem Satz von Ausgangswerten 156. Dieses hochvereinfachte Beispiel wird präsentiert, um ein besseres Verständnis des Basiskonzeptes von syntak­ tischen Mutationen, semantischen Mutationen, feinen und groben Mutationen zu veranschaulichen und zu liefern, wie sie in dem Zusammenhang der Funktionstest-und-Überprüfungs- Umgebung 20 der vorliegenden Erfindung angewendet werden. In einer tatsächlichen Ausführung sind die Computerprogramme, die durch das Funktionstestsystem 22 der vorliegenden Erfin­ dung simuliert und überprüft werden, wahrscheinlich hochkom­ plexe Gebilde mit einer Vielzahl von hierarchisch verwandten Quellcodemodulen, bei denen Mutationsfehler häufig durch mehrere Logikschichten maskiert sind.
Das Computerprogramm 150 dieses exemplarischen Beispiels weist ein einziges Quellcodemodul (Modul "A") 152 auf. Ein Satz von fünf Eingangswerten 154 und ein Satz von fünf Aus­ gangswerten 156 liefern die Eingabe/Ausgabe-Schnittstelle zu/von dem Computerprogramm 150. Die fünf Eingangswerte sind als I(1), I(2), I(3), I(4) und I(5) definiert. Die fünf Aus­ gangswerte sind als O(1), O(2), O(3), O(4) und O(5) defi­ niert.
Fig. 4 stellt drei vereinfachte Implementierungen des Quell­ codemoduls "A" dar, das in Fig. 3 dargestellt ist, wobei eine erste Implementierung 180 ein korrektes Quellcodeseg­ ment enthält, eine zweite Implementierung 183 eine grobe Mutation in das korrekte Quellcodesegment einbringt, und eine dritte Implementierung 187 eine feine Mutation in das korrekte Quellcodesegment einbringt, wobei alle drei Imple­ mentierungen 180, 183 und 187 einer ersten Funktionssimula­ tion (Feinheitsüberprüfung) unterzogen werden.
Die erste Implementierung 180 enthält ein einfaches Pseudo­ codesegment 182, das schleifenhaft fünfmal eine einfache If-Then-Else-Anweisung (Falls-Dann-Andernfalls-Anweisung) durchläuft. Die If-Then-Else-Anweisung ordnet dem Wert von I(Schleifeninkrementwert (CNT)) den Wert von O(Schleifenin­ krementwert) zu, solange der Wert von I(Schleifeninkrement­ wert) kleiner oder gleich fünf ist.
Falls ein einzelner Eingangsvektor gegeben ist, bei dem I(1) = 1, I(2) = 2, I(3) = 3, I(4) = 4 und I(5) = 5 gilt, wie es bei 157 dargestellt ist, erzeugt das Pseudocodesegment 182 einen Ausgangswert von O(1) = 1, O(2) 2, O(3) = 3, O(4) = 4 und O(5) = 5, wie es bei 167 dargestellt ist. Bei diesem Beispiel stellt der einzelne Eingangsvektor 157 die Fein­ heitsüberprüfung des ersten Funktionssimulators dar.
Die zweite Implementierung 183 enthält ein einfaches Pseu­ docodesegment 184 mit einer eingebrachten syntaktischen Mutation 186, derart, daß die If-Then-Else-Anweisung dem Wert von I(Schleifeninkrementwert) einfach den Wert von O(Schleifeninkrementwert) zuordnet, solange der Wert von I(Schleifeninkrementwert) größer oder gleich fünf ist. In anderen Worten ausgedrückt, schaltet die syntaktische Mutation den logischen "Kleiner-als-(<)"-Operator in einen logischen "Größer-als-(<)"-Operator um. Diese syntaktische Mutation ist von dem Typ "unkorrekter logischer Ausdruck", wie er bei 50 in Fig. 1 angezeigt ist.
Das Anlegen des gleichen Eingangsvektors 157 an die zweite Implementierung 183, wie derjenige, der bei der ersten Implementierung 180 angelegt wurde (der Eingangsvektor I(1) = 1, I(2) = 2, I(3) = 3, I(4) = 4 und I(5) = 5), erzeugt einen Ausgangswert von O(1) = 0, O(2) = 0, O(3) = 0, O(4) = 0 und O(5) = 5, wie es bei 169 dargestellt ist. Dies veran­ schaulicht, daß eine sehr kleine syntaktische Veränderung (die Umkehrung eines einzigen logischen Operators) eine sehr große semantische Veränderung ergeben kann (vier von fünf Ausgangswerten haben sich zwischen der ersten und der zwei­ ten Implementierung geändert). Diese kleine syntaktische Veränderung/große semantische Veränderung wird durch die erste Funktionssimulation (Feinheitsüberprüfung) der vorlie­ genden Erfindung als eine grobe Mutation identifiziert, da sich die Ausgangswerte 167 und 169 zwischen der ersten (kor­ rekten) Implementierung 180 und der zweiten mutationsbehaf­ teten Implementierung 183 sehr unterscheiden, wenn die Feinheitsüberprüfung mit dem einzelnen Vektor des ersten Funktionssimulators angelegt wird. An dieser Stelle besteht keine weitere Notwendigkeit dafür, mit einer detaillierteren Funktionsüberprüfung der zweiten Implementierung von Modul A 183 fortzufahren, da dieselbe die Basisfeinheitsüberprüfung nicht bestanden hat.
Die dritte Implementierung 187 enthält ein einfaches Pseudo­ codesegment 188, bei dem eine syntaktische Mutation 190 eingebracht worden ist, derart, daß die If-Then-Else-Anwei­ sung dem Wert von I(Schleifeninkrementwert) einfach den Wert von O(Schleifeninkrementwert) zuordnet, solange der Wert von I(Schleifeninkrementwert) kleiner oder gleich sechs ist. Bei diesem Beispiel ist die einfache eingebrachte syntaktische Mutation ein einfacher typographischer Fehler (Ändern einer "5" in eine "6" in der "If-Then-Else"-Anweisung). Diese syn­ taktische Mutation ist von dem Typ "unkorrekter numerischer Wert" (Fig. 1, Element 52).
Das Anlegen des selben Eingangsvektors 157 an die dritte Implementierung 187 wie derjenige, der bei der ersten Imple­ mentierung 180 und der zweiten Implementierung 183 angelegt wurde (der Eingangsvektor I(1) = 1, I(2) = 2, I(3) = 3, I(4) = 4 und I(5) = 5), erzeugt einen Ausgangswert von O(1) = 1, O(2) = 2, O(3) = 3, O(4) = 4 und O(5) = 5, wie es bei 171 dargestellt ist. In diesem Fall ergibt die sehr kleine syn­ taktische Veränderung eine sehr kleine semantische Verände­ rung. Diese kleine syntaktische Veränderung/kleine seman­ tische Veränderung wird durch die erste Funktionssimulation (Feinheitsüberprüfung) der vorliegenden Erfindung als eine feine Mutation identifiziert, da die Ausgangswerte 167 und 171 zwischen der ersten (korrekten) Implementierung 180 und der dritten mutationsbehafteten Implementierung 187 iden­ tisch sind, wenn die Feinheitsüberprüfung mit dem einzelnen Vektor angelegt wird. In diesem Fall klassifiziert der erste Funktionssimulator die Mutation als eine feine Mutation. Als ein Ergebnis ist eine zweite Funktionssimulation (ein voll­ ständiger Regressionstest) erforderlich, um die Erfassung der feinen Mutation zu versuchen, wie es in Fig. 5 darge­ stellt ist.
Fig. 5 stellt die dritte Implementierung 187 des Quellcode­ moduls, das in Fig. 4 dargestellt ist, dar, wobei die dritte Implementierung eine feine Mutation in das korrekte Quell­ codesegment einbringt, und wobei in einem Versuch, die feine Mutation zu erfassen, die dritte Implementierung einer zwei­ ten Funktionssimulation (einer vollständigen Regressions­ überprüfung) unterzogen wird.
Wie es im vorhergehenden in Fig. 4 beschrieben wurde, ent­ hält die dritte Implementierung 187 ein einfaches Pseudo­ codesegment 188, bei dem eine syntaktische Mutation 190 eingebracht worden ist, derart, daß die If-Then-Else-Anwei­ sung dem Wert von I(Schleifeninkrementwert) einfach den Wert von O(Schleifeninkrementwert) zuordnet, solange der Wert von I(Schleifeninkrementwert) kleiner oder gleich sechs ist. Bei diesem Beispiel ist die eingefügte einfache syntaktische Mutation ein einfacher typographischer Fehler (eine Änderung einer "5" in eine "6" in der "If-Then-Else"-Anweisung). Die­ se syntaktische Mutation ist von dem Typ "unkorrekter nume­ rischer Wert" (Fig. 1, Element 52).
Bei diesem Beispiel wird über den zweiten Funktionssimulator an dem mutationsbehafteten Quellcode 187 ein Drei-Vektor- Regressionstest 200 angelegt. Ein erster Testvektor 202 von I(1) = 1, I(2) = 2, I(3) = 3, I(4) = 4 und I(5) = 5, der an das Computerprogramm angelegt wird, erzeugt einen Ausgangs­ wert von O(1) = 1, O(2) = 2, O(3) = 3, O(4) = 4 und O(5) = 5 von dem mutationsbehafteten Computerprogramm, wie es bei 208 dargestellt ist. Der Ausgangswert, wenn der erste Testvektor 202 an das korrekte (nicht mutationsbehaftete) Computerpro­ gramm angelegt wird, beträgt O(1) = 1, O(2) = 2, O(3) = 3, O(4) = 4 und O(5) = 5, wie es bei 209 dargestellt ist. Folg­ lich ist der erste Testvektor 202 der Regressionstestreihe 200 (der zweite Funktionssimulator) nicht in der Lage, die feine Mutation zu erfassen, die in dem mutationsbehafteten Computerprogramm vorhanden ist.
Auf eine entsprechende Art und Weise erzeugt ein zweiter Testvektor 204 von I(1) = 1, I(2) = 2, I(3) = 3, I(4) = 4 und I(5) = 7 einen Ausgangswert von O(1) = 1, O(2) = 2, O(3) = 3, O(4) = 4 und O(5) = 0 von dem mutationsbehafteten Com­ puterprogramm, wie es bei 210 dargestellt ist. Der Ausgangs­ wert, wenn der zweite Testvektor 204 an das nicht mutations­ behaftete Computerprogramm angelegt wird, beträgt O(1) = 1, O(2) = 2, O(3) = 3, O(4) = 4 und O(5) = 0, wie es bei 211 dargestellt ist. Folglich ist der zweite Testvektor 204 der Regressionstestreihe 200 (der zweite Funktionssimulator) nicht in der Lage, die feine Mutation zu erfassen, die in dem mutationsbehafteten Computerprogramm vorhanden ist.
Schließlich erzeugt der dritte Testvektor 206 von I(1) = 1, I(2) = 2, I(3) = 3, I(4) = 4 und I(5) = 6 einen Ausgangswert von O(1) = 1, O(2) = 2, O(3) = 3, O(4) = 4 und O(5) = 6 von dem mutationsbehafteten Computerprogramm, wie es bei 212 dargestellt ist. Der Ausgangswert, wenn der dritte Testvek­ tor 206 an das nicht mutationsbehaftete Computerprogramm angelegt wird, beträgt O(1) = 1, O(2) = 2, O(3) = 3, O(4) = 4 und O(5) = 0, wie es bei 213 dargestellt ist. Folglich ist der dritte Testvektor 206 der Regressionstestreihe 200 (der zweite Funktionssimulator) in der Lage, einen operations­ mäßigen Unterschied zwischen dem korrekten (nicht mutations­ behafteten) Computerprogramm und dem mutationsbehafteten Programm zu erfassen. In diesem Fall wurde die feine Muta­ tion innerhalb eines vorbestimmten Testmaßes erfaßt, so daß keine Verbesserung der Testreihe 200 erforderlich ist.
Fig. 6 stellt die dritte Implementierung des Quellcode­ moduls, das in Fig. 4 dargestellt ist, dar, wobei die dritte Implementierung eine feine Mutation in das korrekte Quell­ codesegment einbringt, und wobei die dritte Implementierung einer zweiten Funktionssimulation (einer vollständigen Re­ gressionsüberprüfung) unterzogen wird, die nicht in der Lage ist, die feine Mutation zu erfassen.
Wie es im vorhergehenden in Fig. 4 beschrieben wurde, ent­ hält die dritte Implementierung 187 ein einfaches Pseudo­ codesegment 188, in dem eine syntaktische Mutation 190 eingebracht worden ist, derart, daß die If-Then-Else-Anwei­ sung dem Wert von I(Schleifeninkrementwert) einfach den Wert von O(Schleifeninkrementwert) zuordnet, solange der Wert von I(Schleifeninkrementwert) kleiner oder gleich sechs ist. Bei diesem Beispiel ist die einfache syntaktische Mutation ein einfacher typographischer Fehler (Ändern einer "5" in eine "6" in der "If-Then-Else"-Anweisung). Diese syntaktische Mutation ist von dem Typ "unkorrekter numerischer Wert" (Fig. 1, Element 52).
Bei diesem Beispiel wird über den zweiten Funktionssimulator an dem mutationsbehafteten Quellcode 188 ein Drei-Vektor- Regressionstest 220 angelegt. Ein erster Testvektor 222 von I(1) = 1, I(2) = 2, I(3) = 3, I(4) = 4 und I(5) = 5, der an das mutationsbehaftete Computerprogramm angelegt wird, er­ zeugt einen Ausgangswert von O(1) = 1, O(2) = 2, O(3) = 3, O(4) = 4 und O(5) = 5 von dem mutationsbehafteten Computer­ programm, wie es bei 228 dargestellt ist. Der Ausgangswert, wenn der erste Testvektor 222 an ein nicht mutationsbehaf­ tetes Computerprogramm angelegt wird, beträgt O(1) = 1, O(2) = 2, O(3) = 3, O(4) = 4 und O(5) = 5, wie es bei 229 darge­ stellt ist. Folglich ist der erste Testvektor 222 der Re­ gressionstestreihe 220 (der zweite Funktionssimulator) nicht in der Lage, die feine Mutation zu erfassen, die in dem mu­ tationsbehafteten Computerprogramm vorhanden ist.
Auf eine entsprechende Art und Weise erzeugt ein zweiter Testvektor 224 von I(1) = 1, I(2) = 2, I(3) = 3, I(4) = 4 und I(5) = 7 einen Ausgangswert von O(1) = 1, O(2) = 2, O(3) = 3, O(4) = 4 und O(5) = 0 von dem mutationsbehafteten Com­ puterprogramm, wie es bei 230 dargestellt ist. Der Ausgangs­ wert, wenn der zweite Testvektor 224 an ein nicht mutations­ behaftetes Computerprogramm angelegt wird, beträgt O(1) = 1, O(2) = 2, O(3) = 3, O(4) = 4 und O(5) = 0, wie es bei 231 dargestellt ist. Folglich ist der zweite Testvektor 224 der Regressionstestreihe 220 (der zweite Funktionssimulator) nicht in der Lage, die feine Mutation zu erfassen, die in dem mutationsbehafteten Computerprogramm vorhanden ist.
Schließlich erzeugt der dritte Testvektor 226 von I(1) = 1, I(2) = 2, I(3) = 3, I(4) = 4 und I(5) = 8 einen Ausgangswert von O(1) = 1, O(2) = 2, O(3) = 3, O(4) = 4 und O(5) = 0 von dem mutationsbehafteten Computerprogramm, wie es bei 232 dargestellt ist. Der Ausgangswert, wenn der dritte Testvek­ tor 226 an ein nicht mutationsbehaftetes Computerprogramm angelegt wird, beträgt O(1) = 1, O(2) = 2, O(3) = 3, O(4) = 4 und O(5) = 0, wie es bei 233 dargestellt ist. Folglich ist der dritte Testvektor 226 der Regressionstestreihe 220 (der zweite Funktionssimulator) nicht in der Lage, einen opera­ tionsmäßigen Unterschied zwischen dem korrekten (nicht muta­ tionsbehafteten) Computerprogramm und dem mutationsbehafte­ ten Programm zu erfassen.
Da keiner der Testvektoren 222, 224 und 226 der Testreihe 220 in der Lage war, die feine Mutation in dem mutations­ behafteten Computerprogramm zu erfassen, wird die Testreihe 220 verbessert, derart, daß die feine Mutation in dem muta­ tionsbehafteten Computerprogramm erfaßt werden kann. Bei dem dargestellten Beispiel ermöglicht es das Hinzufügen eines vierten Testvektors, bei dem I(1) = 1, I(2) = 2, I(3) = 3, I(4) = 4 und I(5) = 6 gilt, zu der Regressionstestreihe 220, daß die Regressionstestreihe die feine Mutation in dem muta­ tionsbehafteten Computerprogramm erfaßt.
Fig. 7 stellt ein Computersystem 261 und ein externes compu­ terlesbares Medium 260 dar, das das Funktionstestsystem 22 gemäß der vorliegenden Erfindung unterbringt. Ausführungs­ beispiele eines externen computerlesbaren Mediums 260 umfas­ sen eine CD-ROM, ein Diskettenlaufwerk und eine Plattenkas­ sette, sind aber nicht auf dieselben begrenzt. Das Funk­ tionstestsystem 22 der vorliegenden Erfindung kann in einer Vielzahl von kompilierten und interpretierten Computer­ sprachen implementiert sein. Das externe computerlesbare Me­ dium 260 speichert den Quellcode, den Objektcode, den aus­ führbaren Code, die Umgebungsskripten (shell scripts) und/oder Dynamikverbindungsbibliotheken (dynamic link libraries) für das Funktionstestsystem 22. Eine Eingabe­ vorrichtung 263 liest das externe computerlesbare Medium 260 und liefert diese Daten zu dem Computersystem 261. Ausfüh­ rungsbeispiele der Eingabevorrichtung 263 umfassen einen CD-ROM-Leser, ein Diskettenlaufwerk und einen Datenkasset­ tenleser, sind aber nicht auf dieselben begrenzt.
Das Computersystem 261 weist eine Zentralverarbeitungs­ einheit 263 zum Ausführen des Funktionstestsystems 22 auf. Das Computersystem 261 weist ferner einen lokalen Platten­ speicher 264 zum lokalen Speichern des Funktionstestsystems 22 vor, während und nach der Ausführung auf. Das Funktions­ testsystem 22 und seine zugeordnete Umgebung verwenden ferner einen Speicher 266 in dem Computersystem während der Ausführung. Auf das Ausführen des Funktionstestsystems 22 hin werden Ausgangsdaten erzeugt und an eine Ausgabevorrich­ tung 268 geleitet. Ausführungsbeispiele einer Ausgabevor­ richtung 268 umfassen eine Computeranzeigevorrichtung, einen Drucker und/oder eine Plattenspeichervorrichtung, sind aber nicht auf dieselben begrenzt.
Während sich herkömmliche Softwarefunktionstest-und-Über­ prüfungs-Systeme auf Mutationen konzentrierten, die syn­ taktisch klein sind, ohne die semantische Größe zu be­ rücksichtigen, liefert die vorliegende Erfindung eine Vor­ richtung und ein Verfahren zum schnellen Identifizieren der semantischen Größe von kleinen syntaktischen Defekten. Die vorliegende Erfindung filtert schnell einfach erfaßbare syntaktisch kleine Mutationen (d. h. grobe Mutationen) mit einer hohen semantischen Größe heraus, da diese Mutationen die Stärke der Testreihe nicht erhöhen, und richtet die Simulations- und Überprüfungs-Resourcen auf die Erfassung von kleinen Mutationen mit einer kleinen semantischen Größe (d. h. auf feine Mutationen), da die Erfassung dieser feinen Mutationen die Stärke der Testreihe verbessert.
Fachleute auf chemischem, mechanischem, elektromechanischem, elektrischem Gebiet und In­ formatik-Gebiet werden ohne weiteres einsehen, daß die vorliegende Erfindung in einer sehr breiten Vielzahl von Ausführungsbeispielen implementiert sein kann.

Claims (32)

1. Funktionstestsystem, mit
einer Mutationserzeugungseinrichtung (24) zum Erzeugen einer Reihe von mutationsbehafteten Computerprogrammen (25), wobei jedes mutationsbehaftete Computerprogramm (25) eine syntaktische Mutation aufweist;
einem ersten Funktionssimulator (26) zum seriellen Simulieren jedes mutationsbehafteten Computerprogramms (25), wobei der erste Funktionssimulator (26) identifiziert, ob die syntaktische Mutation in jedem mutationsbehafteten Computerprogramm (25) eine grobe syntaktische Mutation ist, und die Funktionssimulation jedes mutationsbehafteten Computerprogramms (25) mit einer identifizierten groben syntaktischen Mutation beendet, und wobei jede syntaktische Mutation, die nicht als eine grobe Mutation identifiziert wird, als eine feine Mutation identifiziert wird; und
einem zweiten Funktionssimulator (28), der eine Folge von Testvektoren verwendet, um jedes mutationsbe­ haftete Computerprogramm (25) mit einer feinen syn­ taktischen Mutation seriell zu simulieren, wobei der zweite Funktionssimulator (28) die Funktionssimulation jedes mutationsbehafteten Computerprogramms (25) be­ endet, falls derselbe die feine syntaktische Mutation innerhalb einer vorbestimmten Simulationsperiode er­ faßt, und wobei der zweite Funktionssimulator (28) eine Anzeige (78) darüber liefert, daß die feine syntaktische Mutation nicht erfaßt wurde, falls der­ selbe die feine syntaktische Mutation nicht innerhalb der vorbestimmten Simulationsperiode erfaßt.
2. Funktionstestsystem gemäß Anspruch 1, bei dem das Computerprogramm (30) eine Mehrzahl von Quellcode­ modulen (32, 34) aufweist.
3. Funktionstestsystem gemäß Anspruch 2, bei dem die Mehrzahl von Quellcodemodulen (32, 34) Funktionsmo­ delle einer integrierten Schaltung darstellt.
4. Funktionstestsystem gemäß Anspruch 2 oder 3, bei dem die Mutationserzeugungseinrichtung (24) aus der Mehr­ zahl von Quellcodemodulen (32, 34) einen Satz (38) von auswählbaren Quellcodemodulen (34) identifiziert, und der Satz (38) von auswählbaren Quellcodemodulen (34) Kandidaten für eine Einfügung einer syntaktischen Mutation darstellt.
5. Funktionstestsystem gemäß Anspruch 4, bei dem aus dem Satz (38) von auswählbaren Quellcodemodulen (34) ein Element auf zufällige Weise ausgewählt wird, und in das Element des Satzes (38) von auswählbaren Quell­ codemodulen (34) eine syntaktische Mutation eingefügt wird.
6. Funktionstestsystem gemäß Anspruch 4, bei dem die Aus­ wahl des Elements aus dem Satz (38) von auswählbaren Quellcodemodulen (34) entsprechend einem gegebenen Verteilungsschema stattfindet.
7. Funktionstestsystem gemäß einem der Ansprüche 1 bis 6, bei dem die Mutationserzeugungseinrichtung (24) aus einem vordefinierten Satz (40) von syntaktischen Muta­ tionstypen (42-54) eine syntaktische Mutation auf zufällige Weise auswählt.
8. Funktionstestsystem gemäß Anspruch 7, bei dem der vor­ definierte Satz (40) von syntaktischen Mutationstypen (42-54) einen logischen Negationsfehler (42) auf­ weist.
9. Funktionstestsystem gemäß Anspruch 7 oder 8, bei dem der vordefinierte Satz (40) von syntaktischen Muta­ tionstypen (42-54) eine Auslassung (48) eines lo­ gischen Ausdrucks aufweist.
10. Funktionstestsystem gemäß einem der Ansprüche 7 bis 9, bei dem der vordefinierte Satz (40) von syntaktischen Mutationstypen (42-54) eine Auslassung (44) eines logischen Faktors aufweist.
11. Funktionstestsystem gemäß einem der Ansprüche 7 bis 10, bei dem der vordefinierte Satz (40) von syntak­ tischen Mutationstypen (42-54) einen unkorrekten logischen Ausdruck (50) aufweist.
12. Funktionstestsystem gemäß einem der Ansprüche 7 bis 11, bei dem der vordefinierte Satz (40) von syntak­ tischen Mutationstypen (42-54) einen unkorrekten logischen Faktor (46) aufweist.
13. Funktionstestsystem gemäß einem der Ansprüche 7 bis 12, bei dem der vordefinierte Satz (40) von syntak­ tischen Mutationstypen (42-54) einen unkorrekten numerischen Wert (52) aufweist.
14. Funktionstestsystem gemäß einem der Ansprüche 7 bis 13, bei dem der vordefinierte Satz (40) von syntak­ tischen Mutationstypen (42-54) eine Fallauslassung (54) aufweist.
15. Funktionstestsystem gemäß einem der Ansprüche 1 bis 14, bei dem die Mutationserzeugungseinrichtung (24) aus einem vordefinierten Satz (40) von syntaktischen Mutationstypen (42-54) eine syntaktische Mutation gemäß einem Verteilungsschema auswählt, das tatsäch­ liche Betriebsbedingungen des Computerprogramms (30) widerspiegelt.
16. Funktionstestsystem gemäß einem der Ansprüche 1 bis 15, bei dem auf das Abschließen der Funktionssimula­ tion hin das Funktionstestsystem einem Benutzer eine statistisch hergeleitete Wahrscheinlichkeit dafür lie­ fert, daß in dem Computerprogramm (30) immer noch unerfaßte tatsächliche Mutationen vorhanden sind.
17. Verfahren zum Bestimmen, ob eine Folge von Testvek­ toren ein Computerprogramm (30) korrekt testet, wobei das Verfahren folgende Schritte aufweist:
  • a) Erzeugen (101, 102, 104, 106, 108, 110) eines mutationsbehafteten Computerprogramms, wobei das mutationsbehaftete Computerprogramm (25) eine syntaktische Mutation aufweist;
  • b) Simulieren (112) des mutationsbehafteten Compu­ terprogramms, um die syntaktische Mutation in dem mutationsbehafteten Computerprogramm (25) als entweder eine feine oder eine grobe syntaktische Mutation zu identifizieren (114);
  • c) falls das mutationsbehaftete Computerprogramm eine grobe syntaktische Mutation aufweist, Be­ enden der Funktionssimulation des mutations­ behafteten Computerprogramms (25), und daraufhin Zurückspringen (116) zu Schritt (a), um ein wei­ teres mutationsbehaftetes Computerprogramm (25) zu erzeugen;
  • d) Simulieren (120) des mutationsbehafteten Compu­ terprogramms (25) mit der feinen syntaktischen Mutation unter Verwendung der Folge von Testvek­ toren, um zu versuchen, die feine syntaktische Mutation in dem mutationsbehafteten Computerpro­ gramm (25) innerhalb einer vorbestimmten Simula­ tionsperiode zu erfassen;
  • e) falls die feine syntaktische Mutation innerhalb einer vorbestimmten Simulationsperiode erfaßt wird, Beenden der Funktionssimulation des muta­ tionsbehafteten Computerprogramms (25) und Zu­ rückspringen (128) zu Schritt (a), um ein weite­ res mutationsbehaftetes Computerprogramm (25) zu erzeugen; und
  • f) falls die feine syntaktische Mutation nicht in­ nerhalb einer vorbestimmten Simulationsperiode erfaßt wird, Anzeigen, daß die feine syntaktische Mutation nicht erfaßt wurde.
18. Verfahren gemäß Anspruch 17, bei dem das Computer­ programm (30) eine Mehrzahl von Quellcodemodulen (32, 34) aufweist.
19. Verfahren gemäß Anspruch 18, bei dem die Mehrzahl von Quellcodemodulen (32, 34) Funktionsmodelle einer inte­ grierten Schaltung darstellt.
20. Verfahren gemäß Anspruch 18, bei dem der Schritt des Erzeugens (101, 102, 104, 106, 108, 110) das Identifi­ zieren (101) eines Satzes (38) von auswählbaren Quell­ codemodulen (34) aus der Mehrzahl von Quellcodemodulen (32, 34) aufweist, und der Satz (38) von auswählbaren Quellcodemodulen (34) Kandidaten für eine Einfügung einer syntaktischen Mutation darstellt.
21. Verfahren gemäß Anspruch 20, bei dem aus dem Satz (38) von auswählbaren Quellcodemodulen (34) ein Element auf zufällige Weise ausgewählt wird, und in das Element des Satzes (38) von auswählbaren Quellcodemodulen (34) eine syntaktische Mutation eingefügt wird.
22. Verfahren gemäß Ansprüch 20, bei dem die Auswahl des Elements aus dem Satz (38) von auswählbaren Quellcodemodulen (34) gemäß einem gegebenen Verteilungs­ schema stattfindet, wobei das Verteilungsschema tat­ sächliche Betriebsbedingungen des Computerprogramms (30) widerspiegelt.
23. Verfahren gemäß einem der Ansprüche 17 bis 22, bei dem der Schritt des Erzeugens (101, 102, 104, 106, 108, 110) das zufällige Auswählen (104) einer syntaktischen Mutation aus einem vordefinierten Satz (40) von syn­ taktischen Mutationstypen (42-54) aufweist.
24. Verfahren gemäß Anspruch 23, bei dem der vordefinierte Satz (40) von syntaktischen Mutationstypen (42-54) einen logischen Negationsfehler (42) aufweist.
25. Verfahren gemäß Anspruch 23 oder 24, bei dem der vor­ definierte Satz (40) von syntaktischen Mutationstypen (42-54) eine Auslassung (48) eines logischen Aus­ drucks aufweist.
26. Verfahren gemäß einem der Ansprüche 23 bis 25, bei dem der vordefinierte Satz (40) von syntaktischen Muta­ tionstypen (42-54) eine Auslassung (44) eines lo­ gischen Faktors aufweist.
27. Verfahren gemäß einem der Ansprüche 23 bis 26, bei dem dar vordefinierte Satz (40) von syntaktischen Muta­ tionstypen (42-54) einen unkorrekten logischen Aus­ druck (50) aufweist.
28. Verfahren gemäß einem der Ansprüche 23 bis 27, bei dem der vordefinierte Satz (40) von syntaktischen Muta­ tionstypen (42-54) einen unkorrekten logischen Fak­ tor (46) aufweist.
29. Verfahren gemäß einem der Ansprüche 23 bis 28, bei dem der vordefinierte Satz (40) von syntaktischen Muta­ tionstypen (42-54) einen unkorrekten numerischen Wert (52) aufweist.
30. Verfahren gemäß einem der Ansprüche 23 bis 29, bei dem der vordefinierte Satz (40) von syntaktischen Muta­ tionstypen (42-54) eine Fallauslassung (54) auf­ weist.
31. Verfahren gemäß einem der Ansprüche 17 bis 30, bei dem die Mutationserzeugungseinrichtung (24) aus einem vor­ definierten Satz (40) von syntaktischen Mutationstypen (42-54) eine syntaktische Mutation gemäß einem Ver­ teilungsschema auswählt, das tatsächliche Betriebsbe­ dingungen des Computerprogramms (30) widerspiegelt.
32. Verfahren gemäß einem der Ansprüche 17 bis 31, bei dem auf das Abschließen der Funktionssimulation hin das Funktionstestsystem dem Benutzer eine statistisch her­ geleitete Wahrscheinlichkeit dafür liefert, daß in dem Computerprogramm (30) immer noch unerfaßte tatsäch­ liche Mutationen vorhanden sind.
DE19959157A 1999-01-25 1999-12-08 Verbessertes Funktionstesten durch das Filtern von groben Mutationen Expired - Fee Related DE19959157C2 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US09/237,286 US6298317B1 (en) 1999-01-25 1999-01-25 Enhanced functional testing through the filtration of non-subtle mutations

Publications (2)

Publication Number Publication Date
DE19959157A1 DE19959157A1 (de) 2000-08-03
DE19959157C2 true DE19959157C2 (de) 2002-04-18

Family

ID=22893107

Family Applications (1)

Application Number Title Priority Date Filing Date
DE19959157A Expired - Fee Related DE19959157C2 (de) 1999-01-25 1999-12-08 Verbessertes Funktionstesten durch das Filtern von groben Mutationen

Country Status (3)

Country Link
US (1) US6298317B1 (de)
JP (1) JP2000222244A (de)
DE (1) DE19959157C2 (de)

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6266654B1 (en) * 1992-12-15 2001-07-24 Softlock.Com, Inc. Method for tracking software lineage
US7831516B2 (en) 1992-12-15 2010-11-09 Sl Patent Holdings Llc System and method for redistributing and licensing access to protected information among a plurality of devices
US7209901B2 (en) 1992-12-15 2007-04-24 Sl Patent Holdings Llc C/O Aol Time Warner Method for selling, protecting, and redistributing digital goods
US7089212B2 (en) * 1992-12-15 2006-08-08 Sl Patent Holdings Llc System and method for controlling access to protected information
US7210128B2 (en) * 2002-10-14 2007-04-24 Fujitsu Limited Event-driven observability enhanced coverage analysis
GB0412611D0 (en) * 2004-06-05 2004-07-07 Ibm Probabilistic regression suites for functional verification
US7320090B2 (en) * 2004-06-09 2008-01-15 International Business Machines Corporation Methods, systems, and media for generating a regression suite database
FR2873832B1 (fr) * 2004-07-30 2006-09-15 Certess Sarl Procede et systeme d'evaluation de tests d'un programme d'ordinateur par analyse de mutations
DE102004037403B4 (de) * 2004-07-30 2008-11-20 Certess S.A. Verfahren zur Bewertung der Güte eines Computerprogrammes
DE102004037402B4 (de) 2004-07-30 2011-02-03 Certess S.A. Verfahren zur Bewertung der Güte eines Testprogrammes
US8291387B2 (en) * 2005-11-22 2012-10-16 International Business Machines Corporation Method and system for testing a software application interfacing with multiple external software applications in a simulated test environment
US7457723B2 (en) * 2006-03-01 2008-11-25 Microsoft Corporation Software performance testing with minimum iterations
US7694253B2 (en) * 2006-05-24 2010-04-06 The Regents Of The University Of California Automatically generating an input sequence for a circuit design using mutant-based verification
DE102006056432A1 (de) * 2006-11-28 2008-05-29 Certess, Inc., Campbell Verfahren zum Testen eines Computerprogramms
US7552361B2 (en) * 2006-12-14 2009-06-23 International Business Machines Corporation Software testing optimization apparatus and method
US9575878B2 (en) * 2009-03-16 2017-02-21 International Business Machines Corporation Data-driven testing without data configuration
CN103164334B (zh) 2011-12-19 2016-03-30 国际商业机器公司 检测web应用自动测试用例中的断裂点的系统和方法
US8938646B2 (en) 2012-10-24 2015-01-20 International Business Machines Corporation Mutations on input for test generation
US9448792B2 (en) 2013-03-14 2016-09-20 Microsoft Technology Licensing, Llc Automatic risk analysis of software
GB2519545A (en) * 2013-10-24 2015-04-29 Ibm Determining a quality parameter for a verification environment
WO2018045585A1 (zh) * 2016-09-12 2018-03-15 深圳中兴力维技术有限公司 一种代码违反项的检查方法及系统
US11237952B1 (en) 2021-04-07 2022-02-01 State Farm Mutual Automobile Insurance Company Runtime class recompilation during mutation testing
US11163675B1 (en) 2021-04-07 2021-11-02 State Farm Mutual Automobile Insurance Company Mutation testing in parallel threads

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5604895A (en) * 1994-02-22 1997-02-18 Motorola Inc. Method and apparatus for inserting computer code into a high level language (HLL) software model of an electrical circuit to monitor test coverage of the software model when exposed to test inputs
US5963739A (en) * 1996-04-26 1999-10-05 Peter V. Homeier Method for verifying the total correctness of a program with mutually recursive procedures
US5754860A (en) * 1996-07-23 1998-05-19 Digital Equipment Corporation Method and apparatus for software testing using a differential testing technique to test compilers

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
VOAS Jeffrey et al, Predicting How Badly "Good" Software Can Behave, in: IEEE Software July/August 1997, S. 73-81 *

Also Published As

Publication number Publication date
JP2000222244A (ja) 2000-08-11
US6298317B1 (en) 2001-10-02
DE19959157A1 (de) 2000-08-03

Similar Documents

Publication Publication Date Title
DE19959157C2 (de) Verbessertes Funktionstesten durch das Filtern von groben Mutationen
DE69817689T2 (de) Modellbasiertes Diagnosesystem mit automatisierten Verfahren für Auswahl von folgendem Test
DE69720821T2 (de) Fehlersuchsystem für Programme mit einer graphischen Benutzerschnittstelle
US6895577B1 (en) Risk metric for testing software
DE3625462A1 (de) Rechnerunterstuetzte fehlerisolation beim pruefen von gedruckten schaltungen
DE10010043A1 (de) Halbleitervorrichtung-Simulationseinrichtung und zugehörige Halbleitertestprogramm-Fehlerbeseitigungseinrichtung
DE102006056432A1 (de) Verfahren zum Testen eines Computerprogramms
DE602004007498T2 (de) Testemulationseinrichtung
DE10392497T5 (de) Herstellungsverfahren und Herstellungsvorrichtung zum Vermeiden eines Prototypen-Aufschubs bei der ASIC/SOC-Herstellung
DE3702408C2 (de)
WO2006105930A1 (de) Diagnosesystem zur bestimmung einer gewichteten liste möglicherweise fehlerhafter komponenten aus fahrzeugdaten und kundenangaben
DE112020007444T5 (de) Automatische Testeinrichtung, Prozess und Computerprogramm zum Testen eines oder mehrerer zu testender Geräte, wobei unterschiedliche Testaktivitäten Teilsätze von Ressourcen des zu testenden Geräts nutzen
DE60002455T2 (de) Verfahren und vorrichtung zur automatischen softwareprüfung
DE19838491B4 (de) Verfahren zur Analyse der Meßstetigkeit von Testgeräten für Halbleiterbauteile
DE112021003677T5 (de) Automatisierte unterstützte schaltkreisvalidierung
DE102013114558A1 (de) Ausschneiden-bei-der Diagnose (CID) - Ein Verfahren zur Verbesserung des Durchsatzes des Vorgangs für Anhebung der Ausbeute
EP0104534B1 (de) Verfahren zur Fehlersuche im Innern von VLSI-Schaltungen mit einer Elektronensonde
DE102006040794A1 (de) Softwareprogramm mit alternativen Funktionsbibliotheken
DE2441486C2 (de) Verfahren zur automatischen Fehlerprüfung eines elektrischen Schaltkreises und Einrichtung zur Durchführung des Verfahrens
DE10111831A1 (de) Verfahren zum automatischen Suchen und Sortieren von Fehlersignaturen von Wafern
DE102021207872A1 (de) Kompositionelle verifikation von eingebetteten softwaresystemen
CN112416807A (zh) 一种测试用例结果分析及关联的系统及方法
DE102019219067A1 (de) Verfahren zur automatischen Qualifizierung eines virtuellen Modells für eine Kraftfahrzeugkomponente
DE4426739C2 (de) Testverfahren sowie Einrichtung zum Erzeugen von Test-Fällen, Testeinrichtung und Programm-Modul dafür
DE19529342C2 (de) Verfahren zur Visualisierung des Überdeckungsgrades beim Test eines endlichen Automaten

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
8127 New person/name/address of the applicant

Owner name: HEWLETT-PACKARD CO. (N.D.GES.D.STAATES DELAWARE),

D2 Grant after examination
8364 No opposition during term of opposition
8327 Change in the person/name/address of the patent owner

Owner name: HEWLETT-PACKARD DEVELOPMENT CO., L.P., HOUSTON, TE

8339 Ceased/non-payment of the annual fee