DE60305073T2

DE60305073T2 - Bidirektionale sondierung von software

Info

Publication number: DE60305073T2
Application number: DE60305073T
Authority: DE
Inventors: Per-Ola Robertsson
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2002-09-23
Filing date: 2003-09-22
Publication date: 2006-09-28
Anticipated expiration: 2023-09-23
Also published as: US20110271256A1; ATE325383T1; JP4959941B2; US8020148B2; EP1576477B1; JP2006500695A; DE60305073D1; WO2004027623A3; CN1701305B; US20040059962A1; CN1701305A; KR20050073458A; KR100976371B1; WO2004027623A2; AU2003267394A1; EP1576477A2

Description

HINTERGRUND DER ERFINDUNG
Gebiet der Erfindung
Die Erfindung bezieht sich auf das Testen von Software, und insbesondere auf ein Verfahren zum bidirektionale Sondieren (Erforschen) von Software.
Beschreibung des Standes der Technik
Unter Entwicklern von Software ist eine der wichtigsten Anforderungen bezüglich der Software, dass sie zuverlässig ist. Zuverlässigkeit verweist auf die Fähigkeit einer Software, für eine spezifizierte Zeitdauer in einer spezifizierten Umgebung ohne Fehler zu arbeiten. Um einen ausreichend hohen Grad von Zuverlässigkeit sicherzustellen, muss Software vor einer Freigabe gründlich getestet und fehlerfrei gemacht (debugged) werden. Siehe z.B. US-Patent 5,581,695, das eine Technik zur Fehlerbeseitigung in Software offenbart. Gewöhnlich wird das gesamte Softwareprogramm als ein ganzes getestet, ebenso wie die einzelnen Funktionskomponenten (z.B. Funktionsaufrufe, Unterprogramme), die das Softwareprogramm ausmachen. Typischerweise werden Testvektoren generiert, die eine Serie von Werten für die Variablen enthalten, die durch die Software und/oder eine oder mehr Funktionskomponenten davon verlangt werden. Die Variablenwerte werden gewählt, verschiedene Typen von Verwendungsbedingungen und Umgebungen darzustellen, in denen beabsichtigt ist, die Software laufen zu lassen. Die Testvektoren werden dann auf die Software und/oder die eine oder mehr Funktionskomponenten davon angewendet, und die Variablenwerte werden beobachtet und aufgezeichnet.
Ein Typ eines Tests, der häufig durchgeführt wird, wird Regressionsanalyse oder manchmal Verifizierungstest genannt. Regressionsanalyse involviert selektives erneutes Testen einer Software, die modifiziert wurde, um bekannte Probleme zu beseitigen. Das selektive erneute Testen wird durchgeführt um sicherzustellen, dass die identifizierten Probleme beseitigt wurden, und dass keine anderen zuvor arbeitenden Funktionskomponenten als ein Ergebnis der Reparaturen fehlgeschlagen sind. Dieser Typ von Test ist im wesentlichen eine Qualitätssteuermaßnahme um sicherzustellen, dass der modifizierte Code noch seinen spezifizierten Anforderungen entspricht und dass beliebiger unveränderter Code durch die Wartungsaktivität nicht beeinträchtigt wurde.
Ein wichtiges Merkmal bei Regressionsanalyse speziell und bei Softwaretest im allgemeinen ist die Fähigkeit, die Variablenwerte zu beobachten, die aus den Testvektoren resultieren. Frühere Versuche, die Variablenwerte einer Software und/oder der Funktionskomponenten davon zu beobachten, haben manuelles Setzen von Unterbrechungspunkten und anderen Fangstellen in dem Quellcode selbst einbezogen. In letzter Zeit enthalten Softwareentwicklungswerkzeuge, wie etwa Code Composer Studio^TM von Texas Instruments und LabVIEW^TM von National Instruments Softwaresondierungen (software probes), die in den im Test befindlichen Code eingefügt werden können. Die Softwaresondierungen erlauben, dass die Variablen in dem im Test befindlichen Code in Echtzeit beobachtet werden, während die Software ausgeführt wird. Diese letzteren Lösungen basieren jedoch nur auf dem Erhalt der Variablenwerte aus dem im Test befindlichen Code heraus (z.B. so, dass sie analysiert werden können). Sie erlauben nicht, dass die Variablenwerte während der Ausführung der Software geändert werden. Mit anderen Worten sind gegenwärtig existierende Softwaresondierungen nur Einbahn- oder unidirektionale Sondierungen dadurch, dass den Daten erlaubt wird, nur von dem im Test befindlichen Code zu dem Testsystem zu fließen. Sie erlauben nicht, dass die Richtung des Datentransfers umgekehrt wird, sodass Daten von dem Testsystem in den im Test befindlichen Code fließen.
Entsprechend wäre es wünschenswert, einen Weg vorzusehen, um Software auf eine Art und Weise derart zu sondieren, dass Daten sowohl aus dem als auch in den im Test befindlichen Code transferiert werden können.
ZUSAMMENFASSUNG DER ERFINDUNG
Die Erfindung wird durch die Ansprüche definiert.
Kurz gesagt richtet sich die vorliegende Erfindung auf bidirektionales Sondieren von Software. Das bidirektionale Sondieren der vorliegenden Erfindung ist zum Transferieren von Daten zu und von einer im Test befindlichen Software fähig. Dieser Zweiwegtransfer von Daten erlaubt, dass die Variablen in der Software nicht nur überwacht, sondern auch geändert werden je nach Erfordernis. Testvektoren können entwickelt und in die Software eingefügt werden, während sie für Testzwecke läuft. Durch Verwenden von Daten von vorherigen Iterationen als eine Eingabe für die nächsten Iterationen wird Regressionsanalyse leichter gemacht.
Im allgemeinen richtet sich die Erfindung in einer Ausführungsform auf ein Verfahren zum Testen von Software mit einer Vielzahl von Datenvariablen und Funktionsargumenten darin. Das Verfahren umfasst Ausführen der Software, Identifizieren einer Adressstelle für mindestens eine der Variablen oder Argumente, die durch die Software verwendet werden, und Ausge ben beliebiger Daten, die in der Adressstelle gespeichert sind, zu einem Testsystem, um dadurch die Daten zu überwachen. Daten von dem Testsystem werden dann in die Adressstelle eingegeben, um dadurch beliebige Daten zu ersetzen, die zuvor in der Adressstelle gespeichert sind.
Im allgemeinen richtet sich die Erfindung in einer anderen Ausführungsform auf eine Vorrichtung zum Testen von Software mit einer Vielzahl von Datenvariablen und Funktionsargumenten darin. Die Vorrichtung umfasst eine zentrale Verarbeitungseinheit, und eine Speichereinheit, die mit der zentralen Verarbeitungseinheit verbunden ist. Die Speichereinheit speichert computerlesbare Instruktionen zum Instruieren der zentralen Verarbeitungseinheit, die Software auszuführen, eine Adressstelle für mindestens eine der Variablen oder Argumente, die durch die Software verwendet werden, zu identifizieren, beliebige Daten, die in der Adressstelle gespeichert sind, zu der zentralen Verarbeitungseinheit auszugeben, um dadurch die Daten zu überwachen, und Daten von der zentralen Verarbeitungseinheit in die Adressstelle einzugeben, um dadurch beliebige Daten zu ersetzen, die zuvor in der Adressstelle gespeichert sind.
Im allgemeinen richtet sich die Erfindung in noch einer anderen Ausführungsform auf ein System zum Testen von Software mit einer Vielzahl von Datenvariablen und Funktionsargumenten darin. Das System umfasst eine im Test befindliche Einrichtung, die konfiguriert ist, die Software auszuführen, einschließlich einer oder mehr Sondierungsinstruktionen in der Software, und einen Tester, der mit der im Test befindlichen Einrichtung verbunden ist. Der Tester ist konfiguriert, die im Test befindliche Einrichtung zu steuern, sodass wenn eine Sondierungsinstruktion ausgeführt wird, die im Test befindliche Einrichtung: eine Adressstelle für mindestens eine der Variablen oder Argumente, die durch die Software verwendet werden, identifizieren wird; beliebige Daten, die in der Adressstelle gespeichert sind, zu dem Tester ausgeben wird; und Daten, die von dem Tester empfangen werden, in die Adressstelle eingeben wird.
Es sollte betont werden, dass der Begriff umfasst/umfassend, wenn in dieser Spezifikation verwendet, genommen wird, um das Vorhandensein von angegebenen Merkmalen, ganzen Zahlen, Schritten oder Komponenten zu spezifizieren, aber das Vorhandensein oder Hinzufügen von einem oder mehr anderen Merkmalen, ganzen Zahlen, Schritten, Komponenten oder Gruppen davon nicht ausschließt.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Ein besseres Verständnis der Erfindung kann durch Verweis auf die folgende detaillierte Beschreibung erhalten werden, wenn in Verbindung mit den begleitenden Zeichnungen aufgenommen, worin:
1 eine beispielhafte Softwaretestumgebung gemäß Ausführungsformen der Erfindung unter Verwendung analoger Hardwarekomponenten veranschaulicht;
2A–2D beispielhafte Betriebsmodi der bidirektionalen Softwaresondierung gemäß Ausführungsformen der Erfindung unter Verwendung analoger Hardwarekomponenten veranschaulichen;
3 ein beispielhaftes System veranschaulicht, in dem die bidirektionale Softwaresondierung gemäß Ausführungsformen der Erfindung implementiert werden kann;
4 ein anderes beispielhaftes System veranschaulicht, in dem die bidirektionale Softwaresondierung gemäß Ausführungsformen der Erfindung implementiert werden kann; und
5 ein beispielhaftes Verfahren zum Implementieren der bidirektionalen Softwaresondierung gemäß Ausführungsformen der Erfindung veranschaulicht.
DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
Es folgt eine detaillierte Beschreibung der Erfindung mit Bezug auf die Zeichnungen, in denen gleiche Bezugszeichen für die gleichen und ähnlichen Elemente genommen werden.
Ausführungsformen der Erfindung sehen ein Verfahren und ein System zum Testen von Software unter Verwendung von bidirektionalen Sondierungen vor. Die bidirektionalen Sondierungen der Erfindung können in den Programmcode in im wesentlichen einer beliebigen Stelle eingefügt werden. Die Sondierungen erlauben, dass Daten abgefangen werden von der ebenso wie eingefügt werden in die Software. Speziell erlauben die Sondierungen, dass die Werte der Variablen in der Software während der Ausführung überwacht, geändert und zurück in die Software eingefügt werden. Die Software wird dann weiter mit den geänderten Werten ausgeführt. Die bidirektionalen Sondierungen der Erfindung können als ein Merkmal oder eine Funktion in einem Softwareentwicklungswerkzeug, wie etwa Code Composer Studio^TM von Texas Instruments und LabVIEW^TM von National Instruments, oder anderen ähnlichen Softwareentwicklungsumgebungen implementiert werden.
Die bidirektionale Softwaresondierungstechnik der vorliegenden Erfindung ist in etwa analog zu dem Testen einer Hardware-Schaltungsplatine. Deshalb wird die Erfindung anfänglich im Sinne eines Testsystems für eine Hardware-Schaltungsplatine beschrieben. Diese Beschreibung ist jedoch nur für veranschaulichende Zwecke vorgesehen, da sich die Erfindung tatsächlich auf die Sondierung von Software richtet.
1 veranschaulicht ein Hardwaretestsystem 100, das dem Softwaretestwerkzeug analog ist, in dem die bidirektionale Sondierungstechnik der vorliegenden Erfindung verwendet werden kann. Das Hardwaretestsystem 100 ist mit einer in Test befindlichen Einrichtung (DUT, device under test) 102 über eine Vielzahl von Hardwaresondierungen verbunden, von denen eine in 104 angezeigt wird. Jede Hardwaresondierung 104 kann durch ihre Sondierungs-ID identifiziert werden. Z.B. ist die erste Sondierung PID 1, die zweite Sondierung ist PID 2, die dritte Sondierung ist PID 3 usw. Die Sondierungen 104 sind mit einer Seite eines Kreuzungsschaltungsbehälters 106 verbunden, dessen andere Seite mit einem oder mehr Funktionsgeneratoren 108, wie etwa Wellenformgeneratoren, und einer oder mehr Messeinheiten 110, wie etwa Oszilloskopen und Wellenmessgeräten, verbunden ist. Der Kreuzungsschaltungsbehälter 106 ermöglicht, dass die Sondierungen 104 selektiv verbunden werden mit und getrennt werden von den Funktionsgeneratoren 108 und den Messeinheiten 110 des Testsystems 100. Eine Steuervorrichtung (nicht ausdrücklich gezeigt) in dem Testsystem 100 stellt ein Steuersignal bereit, das die Konnektivität des Kreuzungsschaltungsbehälters 106 steuert.
Wie gesehen werden kann, sind die Sondierungen 104 strategisch platziert um zu erlauben, dass die elektrischen Signale in gewissen Punkten von Interesse in der DUT 102 untersucht werden. Z.B. ist die erste Sondierung PID 1 in dem Eingang von Func2 platziert um zu erlauben, dass ein elektrisches Signal "a" untersucht wird. Gleichermaßen ist die zweite Sondierung PID 2 in dem Eingang von Func1 platziert um zu erlauben, dass ein elektrisches Signal "b" untersucht wird. Die fünfte Sondierung PID 5 ist jedoch in dem Ausgang von Func1 platziert um zu erlauben, dass ein elektrisches Signal "d" untersucht wird. Die verschiedenen Funktionen (d.h. Func 1–3) können eine beliebige Funktion sein, die durch die DUT durch geführt werden kann (d.h. Addieren, Subtrahieren, Mittelwertbildung etc.). Einige Funktionen können eine oder mehr interne und/oder Unterfunktionen darin haben, die auch getestet werden können. Z.B. hat Func3 eine Unterfunktion "f", die darin enthalten ist, die untersucht werden kann. Auf eine ähnliche Art und Weise zu dem beschriebenen erlaubt die bidirektionale Sondierung der vorliegenden Erfindung, gewisse Variablen von Interesse in der Software zu untersuchen.
Der Verbindungspunkt jeder Sondierung 104 mit der DUT ist analog zu einer typischen Drahtpaarverbindung, die in einem gestrichelten Kreis gezeigt wird, der durch 112 angezeigt wird. Wie gesehen werden kann, führt ein Draht 114 des Drahtpaares 112 von der DUT 102 zu dem Kreuzungsschaltungsbehälter 106, während der andere Draht 116 des Drahtpaares 112 von dem Kreuzungsschaltungsbehälter 106 zurück zu der DUT 102 führt. Ähnlich ist der Verbindungspunkt jeder Sondierung 104 zu dem Kreuzungsschaltungsbehälter 106 analog zu einem Paar von Schaltern, die in dem gestrichelten Kreis gezeigt werden, der durch 118 angezeigt wird. Der eingehende (inbound) Schalter, der bei 120 angezeigt wird, verbindet selektiv den eingehenden Draht 114 einer Sondierung 104 mit dem Testersystem 100 (z.B. mit einer Messeinheit). Der ausgehende (outbound) Schalter, der bei 122 angezeigt wird, verbindet selektiv den zurückführenden Draht 116 einer Sondierung 104 mit entweder dem eingehenden Draht 114 (z.B. für einen normalen Betrieb) oder mit dem Testersystem 100 (z.B. mit einem Funktionsgenerator). Die verschiedenen Betriebsmodi der Schalter werden nachstehend detaillierter beschrieben.
Bezug nehmend nun auf 2A–2D werden die Basisbetriebsmodi der Schalter, die die Sondierungen mit dem Kreuzungsschaltungsbehälter verbinden, gezeigt. Diese Betriebsmodi veranschaulichen grafisch die Funktionsfähigkeit der Softwaresondierung der vorliegenden Erfindung. In dem ersten Betriebs modi, der in 2A gezeigt wird, sind sowohl der eingehende Schalter 120 als auch der ausgehende Schalter 122 von dem Kreuzungsschaltungsbehälter 106 getrennt und sind stattdessen miteinander verbunden. Dies ist der normale Betriebsmodus, wo Daten weder von der DUT 102 in das Testsystem 100 noch von dem Testsystem 100 in die DUT 102 fließen. In dem zweiten Betriebsmodus, der in 2B gezeigt wird, verbindet der eingehende Schalter 120 die DUT 102 mit dem Testsystem 100, während der ausgehende Schalter 122 noch mit dem eingehenden Schalter 120 verbunden ist (d.h. von dem Testsystem getrennt ist). Dieser Betriebsmodus wird verwendet, um Daten von der DUT 102 für Überwachungszwecke zu erhalten. In dem dritten Betriebsmodus, der in 2C gezeigt wird, ist der ausgehende Schalter 122 mit dem Testsystem 100 verbunden, während der eingehende Schalter 120 von dem Testsystem 100 getrennt ist. Dieser Betriebsmodus wird zum Einführen von Daten von dem Testsystem 100 in die DUT 102 für Testzwecke verwendet. In dem vierten Betriebsmodus, der in 2D gezeigt wird, sind sowohl der eingehende Schalter 120 als auch der ausgehende Schalter 122 mit dem Testsystem 100 verbunden. Dieser Betriebsmodus wird verwendet, um Daten von der DUT 102 für Überwachungszwecke zu erhalten ebenso wie zum Einfügen von Daten in die DUT 102 für Testzwecke. Auf eine ähnliche Art und Weise kann die bidirektionale Sondierung der vorliegenden Erfindung verwendet werden, um Daten von den Variablen und Argumenten eines im Test befindlichen Softwareprogramms zu erhalten, Daten in diese Variablen und Argumente einzugeben oder beides.
Nachstehend wird ein beispielhafter Block von Programmcode in einem Beispiel 1 gezeigt, der bidirektionale Sondierungsinstruktionen gemäß Ausführungsformen der Erfindung enthält. Wie gesehen werden kann, ist der Block von Programmcode in Pseudocode geschrieben und nicht in irgendeiner bestimmten Programmiersprache, um das generische Wesen und die Anwend barkeit der bidirektionalen Sondierung zu betonen. In dem Beispiel ist Func0 der im Test befindliche Code und ist analog zu der DUT 102 von 1. Die "Sondierungs"-Instruktionen sind analog zu den Hardwaresondierungen PID 1–5 von 1, und enthalten typischerweise einen Sondierungs-ID ebenso wie eine Angabe der Variable oder des Argumentes, die zu sondieren sind, als Argumente. Z.B. verweist "probe (1, c)" auf den ersten Sondierungs-PID 1 und beeinflusst die Adressstelle entsprechend der Variable "c" in dem im Test befindlichen Code. Somit erlaubt die Sondierungsinstruktion "probe(1,c)", dass die Variable "c" in dem Block von Programmcode überwacht und geändert wird je nach Erfordernis. Gleichermaßen erlaubt die Sondierungsinstruktion "probe(4,a)", dass die Variable "a" überwacht und geändert wird je nach Erfordernis usw.
Beispiel 1
Es wird vermerkt, dass Func3 eine Unterfunktion "f"' hat, Eingaben zu der Variablen "a "'-"d "' sind und die Ausgabe von der eine Variable "e "' ist, entsprechend jeweils Variablen "a"-"d" und "h" von Func0. Unterfunktionen können auch unter Verwendung der bidirektionalen Sondierungstechnik der vorliegenden Erfindung untersucht werden.
Durch Hinzufügen der Sondierungsinstruktionen zu dem im Test befindlichen Code kann die Software beobachtet und deshalb getestet werden. Es können ein beliebiger Typ einer Variable (z.B. automatisch (zeitweilig auf dem Stack gespeichert), global, statisch etc.) oder beliebige gespeicherte Variablen untersucht werden, solange wie sie in dem Adressraum der Sondierung sind, wie durch die Variable in der Sondierungsinstruktion angezeigt wird. Es ist auch möglich, Funktionsargumente unter Verwendung der bidirektionalen Sondierung der vorliegenden Erfindung zu untersuchen. Sondierung der Variablen und Funktionsargumente macht es möglich, die Funktionalität der Software weiter zu testen. Speziell erlaubt Sondierung der Variablen und Argumente einer Funktion, dass zusätzliche Tests und Testvektoren basierend auf den erhaltenen Daten entwickelt werden.
In dem Block von Quellcode, der in dem nachstehenden Beispiel 2 gezeigt wird, kann eine beispielhafte C-Code-Version der Sondierungsinstruktionen gesehen werden. Dieses Beispiel ist vorgesehen um zu veranschaulichen, wie ein tatsächlicher Block von Quellcode unter Verwendung von Ausführungsformen der Erfindung aussehen kann.
Beispiel 2
Die bidirektionale Sondierungstechnik der vorliegenden Erfindung kann in einem beliebigen Testsystem implementiert werden. 3 zeigt ein beispielhaftes Testsystem 300 zum Implementieren der bidirektionalen Sondierungstechnik. Das Testsystem 100 enthält einen Tester 302 und eine im Test befindliche Einrichtung 304, die miteinander in Kommunikation sind. Der Tester 302 ist ein typischer Computer, der eine Zahl von Funktionskomponenten hat, einschließlich einer CPU 306, einer Eingabe-/Ausgabeschnittstelleneinheit 308 und einer Speichereinheit 310. Diese Komponenten sind einem Durchschnittsfachmann in der Computertechnik gut bekannt und werden deshalb hier nur kurz beschrieben. Die CPU 306 behandelt die Ausführung aller Softwareprogramme in dem Tester 302, einschließlich des Betriebssystems und beliebiger Software, die darauf läuft. Die Schnittstelleneinheit 308 dient dazu, den Tester 302 mit der im Test befindlichen Einrichtung 304 in Verbin dung zu bringen, ebenso wie beliebige Eingabe-/Ausgabeeinrichtungen (z.B. Tastatur, Maus, Anzeigeeinheit, Drucker etc.), die dazu verbunden sind. Die Speichereinheit 310 stellt einen zeitweiligen Speicher (z.B. RAM) und/oder einen Langzeitspeicher (z.B. Festplatte) für beliebige Softwareprogramme und/oder Daten bereit, die für die Ausführung des Betriebssystems und der Software, die auf dem Tester 302 läuft, benötigt werden können.
In der Speichereinheit 310 ist eine Reihe von Softwareanwendungen gespeichert, einschließlich eines Softwareentwicklungswerkzeugs 312. Das Softwareentwicklungswerkzeug 312 arbeitet auf die gleiche Weise und hat viele der gleichen Merkmale wie existierende Softwareentwicklungswerkzeuge, wie etwa Code Composer Studio^TM von Texas Instruments und LabVIEW^TM von National Instruments, oder andere ähnliche Softwareentwicklungswerkzeuge. In Übereinstimmung mit Ausführungsformen der Erfindung enthält jedoch das Softwareentwicklungswerkzeug 312 ferner ein Sondierungssteuerungs- und Analysemodul 314. Das Sondierungssteuerungs- und Analysemodul 314 ist zum Steuern der bidirektionalen Sondierung beliebiger Software, die getestet wird, unter Verwendung des Softwareentwicklungswerkzeugs 312, und Analysieren der Daten, die untersucht werden, fähig. Speziell erlaubt das Sondierungssteuerungs- und Analysemodul 314, dass Daten von dem im Test befindlichen Code abgefangen, in den im Test befindlichen Code eingeführt oder beides werden, wie durch einen Benutzer bestimmt wird. Das Sondierungssteuerungs- und Analysemodul 314 erlaubt dem Benutzer auch, Testvektoren basierend auf den erhaltenen Daten zu generieren und die Testvektoren zurück in den im Test befindlichen Code einzuführen. Dies macht es für den Benutzer leichter und bequemer, die Operation und Zuverlässigkeit des im Test befindlichen Codes zu überwachen und zu testen.
In der vorliegenden Ausführungsform wird der im Test befindliche Code, einschließlich der bidirektionalen Sondierungsinstruktionen, in einer getrennten Einheit ausgeführt, nämlich der im Test befindlichen Einrichtung 304, die mit dem Tester 302 in Kommunikation ist. Die im Test befindliche Einrichtung 304, wie der Tester 302, ist ein typischer Computer, der eine Reihe von Funktionskomponenten hat, einschließlich einer CPU 316, einer Eingabe-/Ausgabeschnittstelleneinheit 318 und einer Speichereinheit 320. Die Komponenten der im Test befindlichen Einrichtung 304 sind in der Funktion ihren Gegenstücken in dem Tester 302 ähnlich und werden deshalb hier nicht beschrieben. Der Hauptpunkt besteht darin, dass der im Test befindliche Code 322, einschließlich des untersuchten Quellcodes und der bidirektionalen Sondierungsinstruktionen und Implementierung, gespeichert und getrennt von dem Tester 302 ausgeführt wird. (Siehe die Beispielblöcke von Quellcode oben für die Beispiele von Sondierungsinstruktionen.)
In einigen Ausführungsformen sind jedoch der Tester und die im Test befindliche Einrichtung als ein einzelnes integriertes Testsystem implementiert, das beide Funktionen durchführt. 4 veranschaulicht ein Beispiel eines derartigen Testsystems 400. Das integrierte Testsystem 400 hat eine Reihe von Funktionskomponenten, einschließlich einer CPU 402, einer Eingabe-/Ausgabeschnittstelle 404 und einer Speichereinheit 406. Diese Komponenten sind ihren mit Bezug auf 3 beschriebenen Gegenstücken ähnlich, mit Ausnahme dessen, dass die Speichereinheit 406 sowohl ein Softwareentwicklungswerkzeug 408 als auch einen im Test befindlichen Code 410 darin gespeichert hat. Somit hat das Testsystem 400 vorzugsweise ausreichenden Speicher und Verarbeitungsfähigkeit, um sowohl das Softwareentwicklungswerkzeug 408 als auch den im Test befindlichen Code 410 zur gleichen Zeit auszuführen (d.h. Multitasking). Das Softwareentwicklungswerkzeug 408 ist im wesentlichen das gleiche wie das oben beschriebene Soft wareentwicklungswerkzeug 312, einschließlich eines Sondierungssteuerungs- und Analysemoduls (nicht ausdrücklich gezeigt). Gleichermaßen ist der im Test befindliche Code 410 im wesentlichen der gleiche wie der im Test befindliche Code 322, der oben beschrieben wird, einschließlich des untersuchten Quellcodes und der Sondierungsinstruktionen und Implementierung.
Die Ausführung einer bidirektionalen Sondierungsinstruktion wird in dem beispielhaften Verfahren 500 von 5 gemäß Ausführungsformen der Erfindung veranschaulicht. Ein derartiges Verfahren 500 wird gewöhnlich in der im Test befindlichen Einrichtung implementiert, die den im Test befindlichen Code ausführt, oder einem integrierten Testersystem in einer Multitasking-Umgebung. In dem Verfahren 500 ist ein Block von Quellcode, der eine oder mehr Sondierungsinstruktionen enthält, im Prozess einer Ausführung. In einem gewissen Punkt während der Ausführung des Codes, Schritt 501, wird auf die Sondierungsinstruktionen getroffen. In dem nächsten Schritt, Schritt 502, wird eine Bestimmung bezüglich dessen durchgeführt, ob die Sondierung in den Sondierungsmodus gesetzt wurde. Der besondere Modus wird gewöhnlich durch einen Benutzer über den Tester von dem Softwareentwicklungswerkzeug 312 gesetzt, entweder als ein vorprogrammierter Befehl oder manuell, oder eine Kombination von beiden. Falls die Antwort ja ist, dann werden in dem dritten Schritt 503 die Daten innerhalb des Speichers oder Speicherbereichs, die durch die Sondierungsinstruktion angegeben werden, zu dem Testsystem übertragen, wo sie überwacht und analysiert werden können je nach Erfordernis. Falls nein, dann setzt das Verfahren 500 zu dem vierten Schritt 504 fort, wo eine Bestimmung bezüglich dessen durchgeführt wird, ob die Sondierung in den Einführungsmodus gesetzt wurde. Falls die Antwort ja ist, dann werden in dem fünften Schritt 505 die Daten in dem Speicher oder Speicherbereich, die durch die Sondierungsinstruktion angegeben wer den, überprüft und/oder ersetzt mit neuen Daten, die von dem Testsystem unter Verwendung z.B. einer einfachen Speicherkopie empfangen werden. Falls nein, dann setzt das Verfahren 500 mit der Ausführung des Rests des im Test befindlichen Codes fort.
Es wird vermerkt, dass das oben beschriebene Verfahren 500 eine vereinfachte Implementierung der Sondierungsinstruktion ist. In einigen Ausführungsformen werden zusätzlich zu einer Bestimmung des Sondierungsmodus der Typ der Daten ebenso wie ihre Größe verifiziert. Es ist auch möglich, kompliziertere Variablen zu untersuchen, wie etwa Felder oder sogar Variablen, die nicht in einer kontinuierlichen Struktur gespeichert sind. Auf diese Art und Weise können viele Typen von Daten abgefangen von der, ebenso wie eingefügt werden in die, Software, während sie getestet wird.
Während bestimmte Ausführungsformen und Anwendungen der vorliegenden Erfindung veranschaulicht und beschrieben wurden, ist zu verstehen, dass die Erfindung nicht auf den hierin offenbarten genauen Aufbau und die Zusammenstellungen begrenzt ist, und dass Modifikationen und Variationen an dem Vorangehenden durchgeführt werden können, ohne von dem Bereich der Erfindung abzuweichen, wie in den angefügten Ansprüchen definiert.

Claims

Ein Verfahren zum Testen von Software mit einer Vielzahl von Datenvariablen (a–h) und Funktionsargumenten darin, umfassend: Einfügen einer Sondierungsinstruktion in einen Quellcode der Software in einer vorbestimmten Stelle, wobei die Sondierungsinstruktion auf eine spezifische Datenvariable oder ein Funktionsargument verweist; und Ausführen der Software (322; 410); gekennzeichnet dadurch, dass die Sondierungsinstruktion konfiguriert sein kann, einen Wert, der in der referenzierten Variable oder Funktionsargument gespeichert ist, während Ausführung der Software (505) zu ersetzen und den Wert zu einem Testsystem (302; 400) auszugeben.
Das Verfahren nach Anspruch 1, wobei Daten, die in eine Adressstelle eingegeben sind, um den Wert zu ersetzen, eine überarbeitete Version der Daten sind, die als der Wert zu dem Testsystem von der Adressstelle ausgegeben werden.
Das Verfahren nach Anspruch 1, wobei Daten, die in eine Adressstelle eingegeben sind, um den Wert zu ersetzen, die gleichen wie die Daten sind, die als der Wert zu dem Testsystem von der Adressstelle ausgegeben werden.
Das Verfahren nach Anspruch 1, wobei Daten, die in eine Adressstelle eingegeben sind, um den Wert zu ersetzen, basierend auf den Daten generiert werden, die als der Wert zu dem Testsystem von der Adressstelle während einer vorherigen Iteration ausgegeben werden.
Das Verfahren nach Anspruch 1, wobei Daten, die in eine Adressstelle eingegeben sind, um den Wert zu ersetzen, einen Testvektor von Daten umfassen, der basierend auf Daten generiert wird, die als der Wert zu dem Testsystem von der Adressstelle während einer vorherigen Iteration ausgegeben werden.
Das Verfahren nach einem beliebigen der Ansprüche 2–5, wobei die Adressstelle eine Speicherstelle in einem Computerspeicher (320, 406) identifiziert.
Das Verfahren nach einem beliebigen der Ansprüche 2–5, wobei die Adressstelle eine Speicherstelle in einer Festplatte identifiziert.
Eine Einrichtung zum Testen von Software mit einer Vielzahl von Datenvariablen (a–h) und Funktionsargumenten darin, umfassend: eine zentrale Verarbeitungseinheit (306; 402); eine Speichereinheit (320; 406), die mit der zentralen Verarbeitungseinheit verbunden ist, wobei die Speichereinheit computerlesbare Instruktionen zum Instruieren der zentralen Verarbeitungseinheit speichert, um: die Software auszuführen, einschließlich einer Sondierungsinstruktion in einer vorbestimmten Stelle in einem Quellcode (322; 410) der Software, wobei die Sondierungs instruktion auf eine spezifische Datenvariable oder ein Funktionsargument verweist; gekennzeichnet dadurch, dass die Sondierungsinstruktion konfiguriert sein kann, einen Wert, der in der referenzierten Variable oder dem Funktionsargument gespeichert ist, während Ausführung der Software zu ersetzen und den Wert zu einem Testsystem (302; 400) auszugeben.
Die Vorrichtung nach Anspruch 8, wobei Daten, die in eine Adressstelle eingegeben sind, um den Wert zu ersetzen, eine überarbeitete Version der Daten sind, die als der Wert zu dem Testsystem von der Adressstelle ausgegeben werden.
Die Vorrichtung nach Anspruch 8, wobei Daten, die in eine Adressstelle eingegeben sind, um den Wert zu ersetzen, die gleichen wie die Daten sind, die als der Wert zu dem Testsystem von der Adressstelle ausgegeben werden.
Die Vorrichtung nach Anspruch 8, wobei Daten, die in eine Adressstelle eingegeben sind, um den Wert zu ersetzen, basierend auf Daten generiert werden, die als der Wert zu dem Testsystem von der Adressstelle während einer vorherigen Iteration ausgegeben werden.
Die Vorrichtung nach Anspruch 8, wobei Daten, die in eine Adressstelle eingegeben sind, um den Wert zu ersetzen, einen Testvektor von Daten umfassen, der basierend auf Daten generiert wird, die als der Wert zu dem Testsystem von der Adressstelle während einer vorherigen Iteration ausgegeben werden.
Die Vorrichtung nach einem beliebigen der Ansprüche 9–12, wobei die Adressstelle eine Speicherstelle in einem Computerspeicher (320, 406) identifiziert.
Die Vorrichtung nach einem beliebigen der Ansprüche 9–12, wobei die Adressstelle einer Speicherstelle in einer Festplatte identifiziert.
Ein System zum Testen von Software mit einer Vielzahl von Datenvariablen (a–h) und Funktionsargumenten darin, umfassend: eine Einrichtung in der Prüfung (304), die konfiguriert ist, die Software auszuführen, einschließlich einer oder mehr Sondierungsinstruktionen in einem Quellcode (322) der Software, wobei die eine oder mehr Sondierungsinstruktionen auf spezifische Datenvariablen oder Funktionsargumente verweist; gekennzeichnet durch einen Tester (302), der mit der Einrichtung in der Prüfung (304) verbunden ist, wobei der Tester konfiguriert ist, die Einrichtung in der Prüfung so zu steuern, dass wenn eine Sondierungsinstruktion ausgegeben wird, die Einrichtung in der Prüfung: einen Wert, der in den referenzierten Variablen oder Funktionsargumenten gespeichert ist, während Ausführung der Software ersetzen und den Wert zu dem Tester ausgeben wird, abhängig von einer Konfiguration der einen oder mehr Sondierungsinstruktionen.
Das System nach Anspruch 15, wobei die Daten, die in eine Adressstelle eingegeben sind, um den Wert zu ersetzen, eine überarbeitete Version der Daten sind, die als der Wert zu dem Testsystem von der Adressstelle ausgegeben werden.
Das System nach Anspruch 15, wobei die Daten, die in eine Adressstelle eingegeben sind, um den Wert zu ersetzen, die gleichen wie die Daten sind, die als der Wert zu dem Testsystem von der Adressstelle ausgegeben werden.
Das System nach Anspruch 15, wobei die Daten, die in eine Adressstelle eingegeben sind, um den Wert zu ersetzen, basierend auf Daten generiert werden, die von der Adressstelle während einer vorherigen Iteration ausgegeben werden.
Das System nach Anspruch 15, wobei die Daten, die in eine Adressstelle eingegeben sind, um den Wert zu ersetzen, einen Testvektor von Daten umfassen, der basierend auf Daten generiert wird, die als der Wert zu dem Testsystem von der Adressstelle während einer vorherigen Iteration ausgegeben werden.
Das System nach einem beliebigen der Ansprüche 16–19, wobei die Adressstelle eine Speicherstelle in einem Computerspeicher (320, 406) identifiziert.
Das System nach einem beliebigen der Ansprüche 16–19, wobei die Adressstelle eine Speicherstelle in einer Festplatte identifiziert.