DE202016008043U1

DE202016008043U1 - Vorrichtung zum Erzeugen, Erfassen, Speichern und Laden von Debugging-Informationen für gescheiterte Test-Skripts

Info

Publication number: DE202016008043U1
Application number: DE202016008043.2U
Authority: DE
Original assignee: Google LLC
Current assignee: Google LLC
Priority date: 2015-09-10
Filing date: 2016-08-19
Publication date: 2017-02-21
Anticipated expiration: 2026-08-20
Also published as: JP2018532169A; GB201720879D0; KR20180018722A; GB2555338A; DE112016002814T5; US20170075789A1; CN107820608A; WO2017044291A1; EP3295312A1

Abstract

Eine Erfassungskomponente zur Ablaufverfolgung zum Integrieren von Softwaretestskripten und zum Debuggen, ohne dass ein Benutzereingriff erforderlich ist, wobei die Erfassungskomponente zur Ablaufverfolgung umfasst: eine oder mehrere Verarbeitungsvorrichtungen, um den Status des Software-Test-Skripts zu empfangen ein oder mehrere Speichervorrichtungen, die Anweisungen speichern, die bei Ausführung durch ein oder mehrere Verarbeitungsvorrichtungen, die eine oder mehrere Verarbeitungsgeräte zu Folgendem veranlassen: ausführen eines Softwaretestskripts; und reagieren auf eine nicht erfolgreiche Ausführung des Software-Test-Skripts, wiederholen des Test-Skripts ohne Benutzereingriff; erfassen der Ablaufverfolgung und der zugehörigen Quellcodedaten der Ausführung des Testskripts ohne Benutzereingriff; und speichern der Ablaufverfolgung und der zugehörigen Quellcodedaten der Ausführung des Testskripts ohne Benutzereingriff.

Description

HINTERGRUND
Da Software immer anspruchsvoller wird, ist auch Werkzeuge zu entwerfen, zu entwickeln, zu testen und zu debuggen weiter fortgeschritten. Folglich arbeiten Softwareentwickler zunehmend in Teams zusammen und bauen auf Entwicklungswerkzeuge wie etwa Debugger und Testskripts, um Fehler (die allgemein als ”Bugs” bezeichnet werden) in ihrem Code zu identifizieren und zu beheben.
Unter Schutz gestellt werden und Gegenstand des Gebrauchsmusters sind, entsprechend den Vorschriften des Gebrauchsmustergesetzes, lediglich Vorrichtungen wie in den beigefügten Schutzansprüchen definiert, jedoch keine Verfahren. Soweit nachfolgend in der Beschreibung gegebenenfalls auf Verfahren Bezug genommen wird, dienen diese Bezugnahmen lediglich der beispielhaften Erläuterung der in den beigefügten Schutzansprüchen unter Schutz gestellten Vorrichtung oder Vorrichtungen.
In der Regel ist ein Debugger Teil einer integrierten Entwicklungsumgebungslösung (IDE), ein Werkzeug, das verwendet wird, um Fehler im Quellcode zu identifizieren und zu beheben. Eine gemeinsame Komponente innerhalb von Debugger ist ein ”Durchführungs-Tracer”, der dem Debugger ermöglicht, die Ausführung eines anderen Prozesses, wie die zu entwickelnde Anwendung, aufzuzeichnen, zu beobachten und zu steuern. Während der Ausführung der Anwendung kann ein Debugger auf die ”Kontextinformationen zur Durchführung” der Anwendung zugreifen, während die Anwendung ausgeführt wird. Die Kontextinformationen zur Durchführung einer Anwendung können Informationen wie den Ausführungspfad, Aufrufverlauf eines Verfahrens, Aufrufstapel und die Werte der lokalen und globalen Variablen beinhalten.
Im Allgemeinen wird die Durchführungsverfolgung in Verbindung mit ”Haltepunkten” verwendet. Verfolgungspunkte und Haltepunkte sind nahezu synonym. Der Hauptunterschied besteht darin, dass Verfolgungspunkte automatisch von einem Durchführungs-Tracer festgelegt und behandelt werden. Im Gegensatz dazu wartet ein Haltepunkt darauf, dass der Benutzer die Anwendung wiederaufnimmt. Ein Haltepunkt ist ein bestimmter Codepunkt, der bei Ausführung der Anwendung die Ausführung der Anwendung an diesem Punkt stoppt und dem Entwickler die Kontextinformationen zur Ausführung zur Verfügung stellt. Während die Ausführung angehalten wird, kann der Entwickler die Kontextinformationen zur Ausführung überprüfen, um die Ursache des Fehlers zu bestimmen. Um das Debuggen fortzusetzen, kann der Entwickler die Ausführung der Anwendung fortsetzen, bis ein anderer Haltepunkt erreicht wird oder die Anwendung die Ausführung beendet hat.
Der Prozess des Debuggens kann sehr langwierig, zeitaufwendig sein und erfordert zum Festlegen von Haltepunkten und Ausführen der Anwendung mehrere Zyklen. Wenn ein Test fehlschlägt oder eine Anwendung einen Fehler auslöst, besteht der erste Schritt für den Entwickler im Debugging darin, die Codebereiche zu identifizieren, die möglicherweise den Fehler verursachen, manuell festgelegte Haltepunkte an diesen Codepositionen, manuelles Neustarten der Anwendung mit dem Debugger und dann auf die Ausführung warten, um einen Haltepunkt zu erreichen. Wenn ein Haltepunkt erreicht ist, überprüft der Entwickler die Kontextinformationen zur Ausführung der Anwendung an diesem Punkt, um das Verhalten der Anwendung zu analysieren. Wenn der Entwickler nicht in der Lage ist, die Ursache des Fehlers zu bestimmen, setzt der Entwickler die Ausführung (oder, falls erforderlich, schrittweise zum nächsten Schritt in der Ausführung fort), bis die Ausführung den nächsten Haltepunkt erreicht oder die Ausführung abgeschlossen ist.
Wenn der Fehler nicht beendet werden kann und die Anwendung beendet wurde, muss der Entwickler die Anwendung mithilfe des Debuggers neu starten und andere Haltepunkte manuell nach Bedarf festlegen. Wenn andere Entwickler das Debuggen der Anwendung unterstützen möchten, müssen sie entweder den Zugriff auf die lokale Entwicklungsmaschine gemeinsam nutzen und die oben beschriebenen Schritte verwenden oder die Entwicklungsumgebung (d. h. Quellcode, Binärdateien, Debugger) auf ihren Rechnern replizieren, was zeitraubend sein kann, Ressourcen-intensiv, und immer noch nicht unbedingt dafür sorgen würde, dass der Fehler repliziert werden würde.
Wie von dem Erfinder erkannt wird, ist ein Verfahren oder ein Werkzeug erforderlich, um die Debugging-Informationen zu erzeugen, zu erfassen, zu speichern und zu laden, die zum Debuggen eines Anwendungsfehlers oder eines fehlgeschlagenen Tests erforderlich sind, ohne dass manuelle Neuausführungen der Anwendung oder des Zugriffs auf die lokale Entwicklungsmaschine erforderlich sind.
KURZDARSTELLUNG
Diese Spezifikation beschreibt Technologien, die mit dem Debugging von Software unter Verwendung von Testskripten und speziell mit Verfahren und Systemen zum Erfassen, Speichern und Freigeben von Kontextinformationen zur Ausführung für fehlgeschlagene Testskripts verbunden sind.
Im Allgemeinen kann ein Aspekt des in dieser Beschreibung beschriebenen Gegenstandes in Verfahren und Komponenten zum Integrieren von Softwaretestskripten und zum Erfassen und Speichern von Debugging-Daten ohne jeden weiteren Benutzerzugriff verkörpert werden. Eine exemplarische Komponente beinhaltet ein oder mehrere Verarbeitungsgeräte und ein oder mehrere Speichervorrichtungen, die Anweisungen speichern, die bei der Ausführung durch ein oder mehrere Verarbeitungsgeräte ein oder mehrere Verarbeitungsgeräte veranlassen, ein Beispielverfahren umzusetzen. Ein exemplarisches Verfahren kann das Ausführen eines Software-Test-Skripts umfassen; und auf eine nicht erfolgreiche Ausführung des Software-Testskripts reagieren, wobei das Test-Skript ohne Benutzerzugriff erneut ausgeführt wird; die Ablaufverfolgung und zugehörigen Quellcodedaten der Ausführung des Testskripts ohne Benutzerzugriff erfassen; und die Ablaufverfolgung und zugehörigen Quellcodedaten des Test-Skripts speichern.
Diese und andere Ausführungsformen können optional eines oder mehrere der folgenden Merkmale enthalten: eine nicht erfolgreiche Ausführung kann einen Fehler eines Tests umfassen; eine nicht erfolgreiche Ausführung kann eine Zeitüberschreitung eines Tests umfassen; laden der gespeicherten Trace- und zugehörigen Quellcodedaten zum Debuggen auf einer entfernten Entwicklungsumgebung; speichern und Zugreifen auf die Trace- und zugehörigen Quellcodedaten aus einer Datenbank; speichern und Zugreifen auf die Ablaufverfolgung und zugehörigen Quellcodedaten aus einer lokalen Entwicklungsumgebung; bereitstellen eines gleichzeitigen Zugriffs auf gespeicherte Ablaufverfolgung und zugehörige Quellcodedaten auf mehrere Benutzer über ein Speichermedium wie eine Datenbank; anzeigen der Ablaufverfolgung und zugehörigen Quellcodedaten an einem Benutzer; anzeigen der Ablaufverfolgung und zugehörigen Quellcodedaten in einer integrierten Entwicklungsumgebung (IDE).
Die Einzelheiten von einer oder mehreren Ausführungsformen der Erfindung sind in den begleitenden Zeichnungen dargelegt, die der Veranschaulichung dienen, sowie in der nachstehenden Beschreibung. Andere Merkmale, Aspekte und Vorteile der Erfindung werden aus der Beschreibung, den Zeichnungen und den Ansprüchen deutlich.
Entsprechende Referenznummern und Kennzeichnungen in den verschiedenen Zeichnungen zeigen entsprechende Elemente an
KURZBESCHREIBUNG DER ZEICHNUNGEN
1 ist ein Diagramm, das eine lokale Entwicklungsumgebung darstellt, die die Quellcodedateien, die Binärdateien, die Einheitstestdateien, den Debugger und eine Trace-Erfassungskomponente beinhaltet, die das hierin beschriebene Verfahren ausführt. Ebenfalls dargestellt ist ein Server, der eine Datenbank verwaltet, die die Debugging-Daten enthält.
2 ist eine exemplarische Quellcodedatei einer Klasse, die drei Verfahren deklariert.
2A ist der Beispielquellcode eines Verfahrens, Verfahren A, erklärt in 2.
3A ist ein Ausführungsbeispiel eines Einheitstests für Verfahren A, das „ERFOLG” zurückgibt.
3B ist ein Ausführungsbeispiel eines Einheitstests für Verfahren A, das „FEHLGESCHLAGEN” zurückgibt.
4 ist ein Flussdiagramm eines herkömmlichen Verfahrens eines Entwickler-Debuggens eines Einheitstests.
5 ist ein Flussdiagramm eines exemplarischen Verfahrens zum Erzeugen, Erfassen und Speichern der Debugging-Daten eines Einheitstests, ohne dass eine Benutzerinteraktion erforderlich ist.
6 ist ein Diagramm, das die Debugging-Daten darstellt, die in einer Datenbank gespeichert sind, auf die für mehrere entfernte Benutzer/Entwickler zugänglich ist.
7 ist ein Flussdiagramm eines Verfahrens eines Entwickler-Debugging eines Einheitstests, ohne dass ein Zugriff auf die lokale Entwicklungsumgebung oder eine erneute Ausführung der Anwendung erforderlich ist.
8 ist ein Screenshot einer Benutzerschnittstelle einer IDE, die einen Einheitstest in der lokalen Entwicklungsumgebung debuggt.
9 ist ein Blockdiagramm zur Veranschaulichung eines exemplarischen Computergeräts
AUSFÜHRLICHE BESCHREIBUNG
Die hierin beschriebene exemplarische Ausführungsform umfasst die Schritte zum Generieren, Erfassen, Speichern und Laden von Debugging-Daten für ein ausgefallenes Testskript aus einer lokalen Entwicklungsumgebung, ohne dass ein Entwickler den Debugging-Prozess einrichten oder mit einem aktiven Debugger/Debugging-Prozess interagieren muss. 1 zeigt eine lokale Entwicklungsumgebung (105) und eine Datenbank (155). Die lokale Entwicklungsumgebung (105) kann Quellcodedateien (110), ausführbare Binärdateien (115), die den Quellcodedateien (110) zugeordnet sind, Einheitstests (120) beinhalten, die gegen die Binärdateien (115), einen Debugger (125) zum Erzeugen der Abfolgedaten für die Durchführung und eine Erfassungskomponente zur Ausführung (130) zum Implementieren des hierin beschriebenen Verfahrens ausgeführt werden sollen. Die hier beschriebene lokale Entwicklungsumgebung (105) ist exemplarisch und sollte daher nicht den Rahmen der Erfindung beschränken. In einigen Ausführungsformen kann eine Entwicklungsumgebung (105) anspruchsvoller sein, wobei Quellcode und Binärdateien an mehreren Orten vorhanden sind, was einen Zugriff auf entfernte Bibliotheken und Dienste erforderlich macht. Außerdem verfügt eine Entwicklungsmaschine über eine integrierte Softwareentwicklungsumgebung (IDE).
In einer exemplarischen Ausführungsform kann eine IDE die Quellcode-Dateien, Binärdateien, Debugger, Compiler, Profiler und andere Entwicklungskomponenten in einer integrierten Softwarelösung verwalten. Dieses Ausführungsbeispiel beschreibt die Funktion der Trace-Capture-Komponente (130) mit diesen IDE-Elementen. Obwohl in diesem Beispiel die Erfassungskomponente zur Ausführung (130) als eigenständige Komponente dargestellt ist, kann die Komponente (130) in dem Debugger (125) in anderen Beispielen, in einer IDE als Erweiterung oder auf einem Server als Dienst integriert sein.
1 zeigt auch eine Datenbank (155), die die Debugging-Daten (160, 165, 170) einschließlich der zugehörigen Ablaufverfolgung und Quellcodedaten für einen ausgefallenen Einheitstest speichern kann. Obwohl in dieser exemplarischen Ausführungsform nur fehlgeschlagene Tests behandelt und in der Datenbank (155) gespeichert werden, da im Allgemeinen nur ausgefallene Tests ein Debugging erfordern, ist dieses Verfahren nicht nur auf fehlgeschlagene Tests beschränkt und kann auf alle Debugging, einschließlich erfolgreicher Einheitstests und Anwendungstests im Allgemeinen angewendet werden.
2 ist eine exemplarische Quellcodedatei einer Klasse, die drei Methoden deklariert: Verfahren A (205), Verfahren B (210) und Verfahren C (215). 2A ist ein exemplarischer Quellcode für eine der deklarierten Verfahren, Verfahren A (205). Verfahren A hat zwei Integer-Parameter und kann einen booleschen Wert true oder false zurückgeben. Verfahren A sollte true zurückgeben werden, wenn der erste Parameter x der halbe Wert des zweiten Parameters y ist; ansonsten sollte das Verfahren false zurückgeben. Ein gut konstruierter Satz von Einheitstests, die mit diesem Verfahren verbunden sind, testet diese beiden Fälle: 1) wenn der Wert von x der halbe Wert von y ist und 2) wenn der Wert von x nicht der halbe Wert von y ist. Hier gibt der Quellcode fälschlicherweise immer true zurück, beinhaltet somit einen Fehler. Daher sollte ein Unit-Test für dieses Verfahren testen, wenn der erste Parameter x nicht der halbe Wert des zweiten Parameters y ist und „FAIL” zurückgibt (wie weiter unten in 3B dargestellt), um einen Bug/Fehler im Quellcode zu ermitteln.
3A ist ein Ausführungsbeispiel eines Unit-Tests, der dem Verfahren zugeordnet ist. Verfahren A_Unit-Test1, ist ein Softwareskript, welches das Verfahren A mit den Eingabeparametern 6 und 12 aufruft. In diesem Beispiel ist der Test erfolgreich, da der Unit-Test prüft, ob das Verfahren true zurückgibt, wenn der erste Parameter x der halbe Wert des zweiten Parameters y ist. Da der Wert von 6 die Hälfte von 12 ist, erwartet der Test einen Rückgabewert true und das Verfahren gibt tatsächlich einen Wert true zurück. Somit ist der Test bestanden.
3B ist ein Ausführungsbeispiel eines weiteren Einheitstests. Verfahren A_Unit-Test2 ruft auch das Verfahren A auf, allerdings mit Eingabeparametern von 1 und 10. Da 1 nicht die Hälfte von 10 ist, erwartet der Test einen Rückgabewert false, aber das Verfahren gibt tatsächlich einen Wert true zurück. Somit misslingt der Einheitstest und löst bezüglich eines möglichen Fehlers in der Anwendung einen Alarm aus.
Unit-Tests sind nur ein Mittel zum Ausführen und Testen einer Anwendung. Die hierin verwendeten Einheitstests sind exemplarisch und sollten daher nicht den Rahmen der Erfindung beschränken. Zum Beispiel können andere Testarten allgemeine (Nichteinheit) Testskripts, automatisierte GUI-Test-Tools oder benutzergesteuerte Tests umfassen. Das hierin beschriebenen Verfahren fokussierte Unit-Testarten wobei ein Verfahren zu einem Zeitpunkt getestet wird, ist ebenfalls nur exemplarisch sollte auch nicht den Rahmen der Erfindung beschränken. Die Struktur und Komplexität von Unit-Tests oder anderen Teststrategien, die einer Anwendung in der Entwicklung zugeordnet sind, können je nach Entwicklung und Design der Anwendung variieren.
4 ist ein Flussdiagramm eines herkömmlichen Verfahrens eines Entwickler-Debuggens eines Einheitstests. Im Allgemeinen werden alle oder ein Satz von Einheitstests automatisch ausgeführt oder von einem Entwickler aufgerufen, wenn eine Codeänderung stattgefunden hat und die zugeordneten Binärdateien der Anwendung wiederhergestellt wurden. Die Einheitstests laufen gegen diesen neu erzeugten Aufbau, um die Integrität des Aufbaus zu überprüfen und mögliche Fehler zu erkennen, die sich aus den Codeänderungen ergeben. Herkömmlicher Weise, wenn ein Einheitstest fehlschlägt, durchläuft ein Entwickler einen manuellen Prozess zum Setzen von Haltepunkten im Quellcode und ein erneutes Ausführen der Anwendung unter Verwendung eines Debuggers, um die Kontextinformation zur Ausführung zu überprüfen, wie hierin näher beschrieben.
Das herkömmliche Verfahren beginnt (405) mit der Ausführung eines Einheitstests (410). War der Test erfolgreich (415, 416), keine Fehler wurden ermittelt, macht der Entwickler nichts. (420). Ist der Test fehlgeschlagen (415, 417), überprüft der Entwickler zuerst den Einheitstest (425) und alle zugehörigen Fehler, um die Bereiche des Quellcodes zu bestimmen, die den Fehler verursachen. Als nächstes setzt der Entwickler Haltepunkte in den Bereichen des Codes (430), um den Debugger anzuweisen, die Ausführung der Anwendung an diesen Punkten anzuhalten. Danach startet der Entwickler den Einheitstest mit dem Debugger (435) neu, um die Ausführung der Anwendung zu verfolgen. Wenn die Anwendungsausführung einen Haltepunkt (440, 441) erreicht, stoppt der Debugger die Ausführung der Anwendung an diesem Punkt und stellt dem Entwickler die Kontextinformationen zur Ausführung der Anwendung zur Verfügung. Der Entwickler überprüft diese Informationen (445), um zu versuchen, den Fehler (450) zu lösen.
Wenn der Entwickler in der Lage ist, den Fehler (450, 451) zu lösen, ist das Verfahren abgeschlossen (460) und der Entwickler kann die erforderlichen Quellcodeänderungen implementieren. Wenn jedoch der Entwickler den Fehler (450, 452) nicht lösen kann, setzt der Entwickler die Ausführung der Anwendung (455) fort. Wenn ein anderer Haltepunkt getroffen wird (440, 441), wird die Ausführung erneut angehalten, und der Entwickler wiederholt die Prüfschritte der Kontextinformation zur Ausführung (445) am Haltepunkt, um zu versuchen, den Fehler zu lösen. Die Ausführung kann fortgesetzt werden, ohne dass Haltepunkte erreicht werden (440, 442), d. h. die Ausführung beendet oder wird beendet und der Fehler besteht weiterhin.
Der Entwickler kehrt dann zum Prüfschritt des Einheitstests (425) zurück. Wie dargestellt, kann dieser Prozess für einen Entwickler sehr zeitaufwendig und langwierig sein, was möglicherweise mehrere Zyklen erfordert, um die Einheitstests, Quellcodedateien, das Festlegen von Haltepunkten und das erneute Ausführen der Anwendung manuell zu überprüfen. Außerdem erfordert es einen Entwickler, um auf die lokale Entwicklungsmaschine zuzugreifen, auf der sich die Anwendung befindet, der die Anwendung mithilfe des Debuggers ausführt und manuell Haltepunkte im zugehörigen Quellcode setzt, um die Kontextinformationen zur Ausführung für die Anwendung zu überprüfen.
5 ist ein Flussdiagramm, welches das exemplarische Verfahren zum Erzeugen, Erfassen und Speichern der relevanten Debugging-Daten, die durch eine Erfassungskomponente zur Ausführung erzeugt werden, nach der Ausführung eines fehlgeschlagenen Einheitstests ohne Benutzereingriff, gemäß dem Ausführungsbeispiel dargestellt wird. Obwohl in dieser exemplarischen Ausführungsform ein ”fehlgeschlagener Einheitstest” einen Fall repräsentiert, in dem ein erwarteter Rückgabewert nicht mit dem tatsächlichen Rückgabewert übereinstimmt, sollte er nicht den Rahmen der Erfindung beschränken. ”Failed” kann auch Fälle umfassen, in denen der Code ineffizient oder nicht performant ist.
Ein exemplarisches Verfahren beginnt (505) mit der Ausführung eines Einheitstests (510). War der Test erfolgreich (515, 516), kann das Verfahren nichts tun (520). Wenn der Test fehlschlägt (515, 517), was bedeutet, dass die Ausführung eines Softwaretestskripts nicht erfolgreich ist, kann das exemplarische Verfahren automatisch ohne Benutzereingriff, den Einheitstest mithilfe eines Debuggers und einer Ausführungsverfolgung, die aktiviert ist (525), erneut ausführen. Dieser Schritt zum erneuten Ausführen steht im Gegensatz zu dem herkömmlichen Verfahren, bei dem der Entwickler diesen Schritt manuell (435), möglicherweise mehrere Male (450, 452) und mit einigen anderen vorherigen Schritten durchführt, wie etwa das Überprüfen des Quellcodes (425) und Setzen der manuellen Haltepunkte (430). Bei diesem exemplarischen Verfahren kann die Erfassungskomponente zur Ausführung automatisch ohne Benutzereingriff Verfolgungspunkte für jede Zeile des Quellcodes, die dem Ausführungspfad (530) des Einheitstests zugeordnet ist, festlegen und die Kontextinformationen zur Ausführung für jede Zeile des Quellcodes (535) erfassen. Die Erfassungskomponente zur Ausführung kann auch so konfiguriert/optimiert werden, dass sie automatisch, ohne Benutzereingriff die Kontextinformationen zur Ausführung auf Basis bestimmter Faktoren wie Standort, Typ und Größe von Quellcodedateien speichern und erfassen können. Dies sind nur einige exemplarische Faktoren, um die Wirksamkeit und Effizienz der Erfassungskomponente zur Ausführung/Verfahren zu verbessern und sollten nicht den Rahmen der Erfindung beschränken. Eine Ausführung eines Softwaretestskripts ist im Falle eines Fehlers eines Tests oder im Falle eines Timeouts eines Tests nicht erfolgreich.
Im Gegensatz dazu untersucht der Entwickler den Unit-Test, um die zugehörigen Quellcodedateien (425) zu bestimmen und manuell Haltepunkte (430) im zugehörigen Quellcode zu setzen, um diese Codebereiche zu verfolgen und die Kontextinformationen zur Ausführung (445) an diesen Punkten zu überprüfen.
In dem exemplarisches Verfahren können dann die entsprechenden erfassten Verfolgungsdaten (d. h. Die Kontextinformationen zur Ausführung und der zugehörige Quellcode) auf einer Datenbank oder einem anderen Speichermedium (540) zur Überprüfung durch mehrere Entwickler gespeichert und darauf zugegriffen werden. In einigen Beispielen können die entsprechenden Verfolgungsdaten nur für einen ausgefallenen Einheitstest gespeichert werden. Es wird für mehrere Benutzer ein gleichzeitiger Zugriff für die gespeicherte Ablaufverfolgung und der zugehörigen Quellcodedaten bereitgestellt. Damit ist das exemplarische Verfahren (545) vervollständigt und die erfassten Debugging-Daten für den Einheitstest können nun von jedem Entwickler verwendet werden, um den Fehler zu debuggen, ohne die Anwendung erneut ausführen oder auf die lokale Entwicklungsmaschine zugreifen zu müssen. Dies steht im Gegensatz zu einem herkömmlichen Verfahren, bei dem der Entwickler auf die lokale Entwicklungsmaschine zugreift und die Anwendung während des Betriebs debuggt.
6 ist eine exemplarische Datenbank (605), die die Debugging-Daten für das Verfahren S Einheitstest2 (610) beinhaltet. Basierend auf unserem Beispiel in 3B und dem Flussdiagramm aus 5, sollte dies das Ergebnis sein, wenn das Verfahren, wie im Ausführungsbeispiel beschrieben, angewendet wird. Wie gezeigt, können mehrere Benutzer (615, 620, 625), wie beispielsweise der ursprüngliche Entwickler oder andere Entwickler im Team, auf die Debugging-Daten (630) zugreifen und diese abrufen (die erfassten Kontextinformationen zur Ausführung und den zugehörigen Quellcode für einen Einheitstest) und ohne die Anwendung oder den Zugriff auf die lokale Entwicklungsumgebung erneut ausführen zu müssen, in ihrer lokalen Maschine ab- und aufrufen.
7 ist ein Flussdiagramm eines Verfahrens eines Entwickler-Debugging eines Einheitstests, ohne dass ein Zugriff auf die ursprüngliche lokale Entwicklungsumgebung oder eine erneute Ausführung der Anwendung erforderlich ist. Ein exemplarisches Verfahren beginnt (705), wo der Entwickler Debugging-Daten für einen Einheitstest (710) laden kann, der (wie in 5 beschrieben) erfasst und gespeichert werden kann (wie in 6 beschrieben). Unter Verwendung dieser Daten kann der Entwickler den Ausführungskontext und den zugehörigen Quellcode in einer Benutzerschnittstelle wie einer integrierten Entwicklungsumgebungssoftware (IDE) überprüfen, um den Fehler von der lokalen Maschine (715) zu beheben (d. h. nicht die ursprüngliche Entwicklungsmaschine) ohne die Anwendung oder den Einheitstest erneut auszuführen.
8 ist ein Beispiel eines Screenshots einer IDE-Benutzerschnittstelle in einer neuen Entwicklungsumgebung, in diesem Fall Local Development Environment 2, mit Debugging-Daten für VerfahrenA_Einheitstest2_Debug-Daten. In diesem Beispiel wurden die Debugging-Daten für den fehlgeschlagenen Einheitstest erfasst, gespeichert und nun lokal in eine andere neue Entwicklungsumgebung, die lokale Entwicklungsumgebung 2 (800), als das Original (105) geladen. Dieses Beispiel UI stellt eine IDE-Software (805) dar, die einem Entwickler ermöglicht und gestattet, die zugehörigen Quellcodedateien (815, 816, 817) für einen Einheitstest auszuwählen. Die Benutzeroberfläche bietet auch Debugging-Funktionalität, wie beispielsweise „Schritt zurück” (820), „Schritt nach vorne” (821), „Schritt in ein Verfahren” (822) und „Schritt aus einem Verfahren” (823), um durch die Ausführungsverfolgung einer Anwendung zu navigieren, ähnlich, wie wenn die Anwendung tatsächlich auf einer lokalen Maschine ausgeführt wird. Hier wird die Funktion „Schritt in das Verfahren” nicht aktiviert, da der Ausführungspunkt (835) nicht auf einer Codezeile liegt, die ein Verfahrensaufruf ist. Die erfassten Debugging-Daten aus der Erfassungskomponente zur Ausführung ermöglicht einem Entwickler eine ähnliche Funktionalität zu einem Debugger auf der ursprünglichen lokalen Entwicklungsumgebung. Ein internes Fenster (825) zeigt auch den entsprechenden Quellcode, in diesem Fall für das Verfahren A, zusammen mit den Zeilennummern (830) an. Der aktuelle Ausführungspunkt (835) im Debugging-Prozess wird auch für den Entwickler hervorgehoben. Zu diesem Zeitpunkt (835) werden die Kontextinformationen zur Ausführung im nachfolgenden Fenster dargestellt (845). Der markierte aktuelle Ausführungspunkt (835) und die Debugging-Informationen (840–845) werden als Entwickler-„Schritte” (820–823) aktualisiert oder klicken auf verschiedene Zeilen (830) im Quellcode. Der Entwickler kann auch die Art der anzuzeigenden Kontextinformationen zur Ausführung (840–843), wie lokale Variableninformationen (840), Aufrufstapeldaten (841), Verfahrensverlauf (842) oder Variablenverlauf (843) auswählen. In diesem Screenshot sind „lokale” (840) ausgewählt, die während der Ausführung des Einheitstests die Werte der lokalen Variablen an der Zeile 8 des Ausführungspunkts (835) anzeigen (845). Nun kann der Entwickler festlegen, dass in diesem Fall die lokalen Variablen korrekt geladen werden, der Rückgabewert aber falsch ist, wodurch der Fehler beseitigt wird.
9 ist ein Blockdiagramm auf hohem Niveau, um eine Anwendung auf einem Computergerät (900) zu zeigen. In einer Basiskonfiguration (901) umfasst das Computergerät (900) typischerweise einen oder mehrere Prozessoren (910), einen Systemspeicher (920) und einen Speicherbus (930). Der Speicherbus kann für die Kommunikation zwischen den Prozessoren und dem Systemspeicher verwendet werden. Die Konfiguration kann auch eine eigenständige Trace-Erfassungskomponente (926) umfassen, die das oben beschriebene Verfahren implementiert, oder kann in einer Anwendung (922, 923) integriert werden.
In Abhängigkeit von verschiedenen Konfigurationen kann der Prozessor (910) ein Mikroprozessor (μP), ein Mikrokontroller (μC), ein digitaler Signalprozessor (DSP) oder eine beliebige Kombination davon sein. Der Prozessor (910) kann eine oder mehrere Zwischenspeicher-Ebenen einschließen, wie einen Zwischenspeicher auf Ebene L1 (911) und einen Zwischenspeicher auf Ebene L2 (912), einen Prozessorkern (913) und ein Register (914). Der Prozessorkern (913) kann eine arithmetisch-logische Einheit (ALU, arithmetic logic unit), einen Gleitkommaprozessor (FPU, floating point unit), einen digitalen Signalverarbeitungskern (DSP Core, digital signal processing core), oder eine beliebige Kombination davon enthalten. Eine Speicher-Controller (916) kann entweder ein unabhängiges Teil oder ein interner Teil des Prozessors (910) sein.
Abhängig von der gewünschten Konfiguration kann der Systemspeicher (920) jeglichen Typs sein, einschließlich, jedoch nicht beschränkend auf flüchtige Speicher (wie RAM), nicht flüchtige Speicher (wie ROM, Flash-Speicher usw.) oder jegliche Kombination hiervon. Ein Systemspeicher (920) umfasst typischerweise ein Betriebssystem (921), eine oder mehrere Anwendungen (922) und Programmdaten (924). Die Anwendung (922) kann eine Trace-Erfassungskomponente (926) oder ein System und ein Verfahren zum Erzeugen, Erfassen, Speichern und Laden von Debugging-Daten (923) einer Ausführung einer Anwendung oder eines Tests umfassen. Die Programmdaten (924) enthalten das Speichern von Anweisungen, die, wenn sie von der einen oder mehreren Verarbeitungsvorrichtungen ausgeführt werden, ein System und Verfahren für das beschriebene Verfahren und die beschriebene Komponente. implementieren. (923). Oder es können Anweisungen und Implementierung des Verfahrens über die Trace-Erfassungskomponente (926) ausgeführt werden. In einigen Ausführungsformen kann die Anwendung (922) so angeordnet werden, dass sie mit Programmdaten (924) in einem Betriebssystem (921) funktioniert.
Das Computergerät (900) kann zusätzliche Eigenschaften oder Funktionen sowie zusätzliche Oberflächen haben, um die Kommunikation zwischen der Basiskonfiguration (901) und allen erforderlichen Geräten und Oberflächen zu erleichtern.
Der Systemspeicher (920) ist ein Beispiel eines Computerspeichermediums. Computerspeichermedien enthalten, sind aber nicht beschränkt auf RAM, ROM, EEPROM, Flash-Speicher oder andere Speichertechnologie, CD-ROM, Digitalversatile-Disks (DVD) oder andere optische Speicher, Magnetkassetten, Magnetbänder, Magnetplattenspeicher oder andere magnetische Speichervorrichtungen oder jedes andere Medium, das verwendet werden kann, um die gewünschte Information zu speichern, und auf die durch die Rechenvorrichtung 700 zugegriffen werden kann. Jedes solches Computer-Speichermedium kann Teil des Geräts (900) bilden.
Das Computergerät (900) kann als Teil eines kleinformatigen tragbaren (bzw. mobilen) elektronischen Geräts, wie Mobiltelefon, Smartphone, PDA (personal data assistant), ein persönliches Medienabspielgerät, ein Tabletcomputer (Tablet), ein drahtloses Web-Watch-Gerät, ein persönliches Headset-Gerät, ein anwendungsspezifisches Gerät oder ein Hybridgerät, sein, das beliebige von den obigen Funktionen beinhaltet. Das Computergerät (900) kann auch als PC (Personal Computer) einschließlich Laptop- und Nicht-Laptop-Computerkonfigurationen ausgeführt werden.
Die vorangegangene detaillierte Beschreibung legt verschiedene Ausführungsformen der Geräte und/oder Prozesse über die Nutzung von Blockdiagrammen, Flowcharts und/oder Beispiele dar. Insofern, als solche Blockdiagramme, Flussdiagramme und/oder Beispiele eine oder mehrere Funktionen und/oder Tätigkeiten enthalten, ist es für Fachleute offensichtlich, dass jede Funktion und/oder Tätigkeit innerhalb solcher Blockdiagramme, Flussdiagramme oder Beispiele implementiert werden können, einzeln und/oder zusammen, durch eine breite Palette an Hardware, Software, Firmware oder praktisch jeder möglichen Kombination davon. In einer Ausführungsform können einige Teile des hier beschriebenen Gegenstands über anwendungsspezifische integrierte Schaltungen (ASICs), Field Programmable Gate Arrays (FPGAs), digitale Signalprozessoren (DSPs) oder andere integrierte Formate implementiert werden. Dennoch werden die Fachkundigen feststellen, dass einige Aspekte der hier dargelegten Ausführungen, teilweise oder gänzlich, ebenso in integrierten Kreisläufen implementiert werden können, als ein oder mehrere Computerprogramme, die auf einem oder mehreren Computern ausgeführt werden, als ein oder mehrere Programme, die auf einem oder mehreren Prozessoren ausgeführt werden, als Firmware oder irgend eine Kombination davon; und dass ein Entwurf der Kreisläufe und/oder des Schreibens des Codes für die Software und/oder Firmware unter Berücksichtigung der vorliegenden Veröffentlichung eine große Leistung wäre. Außerdem werden Fachleute verstehen, dass die Mechanismen dieses hier beschriebenen Gegenstands in der Lage sind, als ein Programmprodukt in einer Vielzahl von Formen verteilt zu werden, und dass eine veranschaulichende Ausführungsform des hier beschriebenen Gegenstands unabhängig von der besonderen Art des nichtflüchtigen signalführenden Mediums gilt, das für die tatsächliche Verteilung verwendet wird. Beispiele für ein nicht-transitorisches Signal tragenden Mediums umfassen, ohne Einschränkung darauf, Folgendes: Floppy Disk, Festplattenlaufwerk, CD (Compact Disc), DVD (Digital Video Disk), digitales Band, Computerspeicher usw.; sowie ein Medium des Übertragungstyps, wie beispielsweise ein digitales und/oder analoges Kommunikationsmedium. (beispielsweise ein Glasfaserkabel, Wellenleiter, verdrahtete und drahtlose Kommunikationsverbindung usw.)
Was die Nutzung von im Wesentlichen allen Mehrzahl- und/oder Einzahlbegriffen hierin betrifft, können die Experten je nach Eignung für den Kontext und/oder die Anwendung die Mehrzahlform zur Einzahlform und vice versa bilden. Die verschiedenen Singular-/Plural-Permutationen können hierin ausdrücklich aus Gründen der Klarheit dargelegt.
Folglich wurden bestimmte Ausführungsformen des Gegenstands beschrieben. Weitere Ausführungsformen gehören zum Umfang der folgenden Ansprüche. In einigen Fällen können die in den Ansprüchen beschriebenen Handlungen in einer anderen Reihenfolge ausgeführt werden und dennoch erwünschte Ergebnisse erzielen. Zusätzlich erfordern die in den beigefügten Figuren dargestellten Prozesse nicht notwendigerweise die bestimmte gezeigte Reihenfolge oder aufeinanderfolgende Reihenfolge, um erwünschte Ergebnisse zu erzielen. Bei bestimmten Implementierungen können Multitasking und eine Parallelbearbeitung vorteilhaft sein.
Gemäß den exemplarischen Ausführungsformen werden ein Verfahren und ein System zum Erzeugen, Erfassen, Speichern und Laden von Debugging-Daten für ein fehlgeschlagenes Testskript ohne Benutzerinteraktion offenbart. In einer exemplarischen Ausführungsform wird eine Trace-Erfassungskomponente automatisch ein fehlgeschlagenes Testskript ausführen und die Kontextinformation zur Ausführung und die Quellcodedateien, die dem fehlgeschlagenen Testskript zugeordnet sind, während der Wiederholung des Testskripts erfassen. Die Ausführung von Kontextinformationen und der zugeordnete Quellcode werden auf einer Datenbank oder einem anderen gemeinsam genutzten Speichermedium gespeichert und sind für mehrere Benutzer zugänglich, um ein gleichzeitiges Debuggen durch mehrere Benutzer zu ermöglichen. Die erfassten Informationen ermöglichen das Debuggen des ausgefallenen Testskripts, ohne dass ein Zugriff auf die ursprüngliche Maschine oder eine erneute Ausführung der Anwendung erforderlich ist.
Nachfolgend werden weitere Beispiele für das System und das Verfahren gemäß der vorliegenden Offenbarung beschrieben.
Ein erstes Beispiel betrifft ein Verfahren zum Integrieren von Softwaretestskripten und zum Debuggen, ohne dass ein Benutzereingriff erforderlich ist, wobei das Verfahren umfasst: Ausführen eines Softwaretestskripts; und auf eine nicht erfolgreiche Ausführung des Software-Testskripts reagiert, wobei das Test-Skript ohne Benutzereingriff erneut ausgeführt wird; erfassen der Ablaufverfolgung und zugehörigen Quellcodedaten der Ausführung des Testskripts; und Speichern der Ablaufverfolgung und zugehörigen Quellcodedaten der Ausführung des Testskripts ohne Benutzereingriff.
In einem zweiten Beispiel, basierend auf dem ersten Beispiel, ist eine nicht erfolgreiche Ausführung ein Fehler eines Tests.
In einem dritten Beispiel, basierend auf dem zweiten Beispiel, ist eine nicht erfolgreiche Ausführung ein Timeout eines Tests.
In einem vierten Beispiel, basierend auf dem ersten bis dritten Beispiel, umfasst das Verfahren ferner das Laden der gespeicherten Ablaufverfolgung und zugehörigen Quellcodedaten Debuggen auf einer entfernten Entwicklungsumgebung.
In einem fünften Beispiel, basierend auf dem ersten bis vierten Beispiel, umfasst das Verfahren ferner das Zugreifen und Speichern der Ablaufverfolgung und zugehörigen Quellcodedaten aus einer Datenbank.
In einem sechsten Beispiel, basierend auf dem ersten bis vierten Beispiel, umfasst das Verfahren ferner das Zugreifen und Speichern auf die Ablaufverfolgung und zugehörigen Quellcodedaten auf einer lokalen Entwicklungsumgebung.
In einem siebten Beispiel, basierend auf dem ersten bis sechsten Beispiel, umfasst das Verfahren ferner das Bereitstellen eines gleichzeitigen Zugriffs auf gespeicherte Ablaufverfolgung und zugehörigen Quellcodedaten auf mehrere Benutzer über ein Speichermedium wie eine Datenbank.
In einem achten Beispiel, basierend auf dem ersten bis siebten Beispiel, umfasst das Verfahren ferner das Anzeigen der Ablaufverfolgung und der zugehörigen Quellcodedaten an einen Benutzer.
In einem neunten Beispiel, basierend auf dem ersten bis achten Beispiel, umfasst das Verfahren ferner das Anzeigen der Ablaufverfolgung und der zugehörigen Quellcodedaten in einer integrierten Entwicklungsumgebung (IDE).
Ein zehntes Beispiel betrifft eine Erfassungskomponente zur Ablaufverfolgung zum Integrieren von Softwaretestskripten und zum Debuggen, ohne dass ein Benutzereingriff erforderlich ist, wobei das Erfassungskomponente zur Ablaufverfolgung umfasst: eine oder mehrere Verarbeitungsvorrichtungen, um den Status des Softwaretestskripts zu empfangen; Eine oder mehrere Speichereinrichtungen, die Befehle speichern, die, wenn sie durch die eine oder die mehreren Verarbeitungsvorrichtungen ausgeführt werden, die eine oder die mehreren Verarbeitungsvorrichtungen veranlassen: ein Software-Test-Skript auszuführen; und reagieren auf eine nicht erfolgreiche Ausführung des Software-Test-Skripts, erneutes Ausführen des Test-Skripts ohne Benutzereingriff; erfassen der Ablaufverfolgung und der zugehörigen Quellcodedaten der Ausführung des Testskripts; und Speichern der Ablaufverfolgung und der zugehörigen Quellcodedaten der Ausführung des Testskripts ohne Benutzereingriff.
In einem elften Beispiel, basierend auf dem zehnten Beispiel, repräsentiert ein Status einen Ausfall eines Tests.
In einem zwölften Beispiel, basierend auf dem zehnten oder elften Beispiel, repräsentiert ein Status ein Timeout eines Tests dar.
In einem dreizehnten Beispiel, basierend auf dem zehnten bis zwölften Beispiel, umfasst die Erfassungskomponente zur Ablaufverfolgung ferner das Laden der gespeicherten Ablaufverfolgung und zugehörigen Quellcodedaten zum Debuggen auf einer entfernten Entwicklungsumgebung.
In einem vierzehnten Beispiel, basierend auf dem zehnten bis dreizehnten Beispiel, umfasst Erfassungskomponente zur Ablaufverfolgung ferner das Zugreifen und Speichern der Ablaufverfolgung und zugehörigen Quellcodedaten aus einer Datenbank.
In einem fünfzehnten Beispiel, basierend auf dem zehnten bis dreizehnten Beispiel, umfasst Erfassungskomponente zur Ablaufverfolgung ferner das Zugreifen und Speichern der Ablaufverfolgung und zugehörigen Quellcodedaten von einer lokalen Entwicklungsumgebung.
In einem sechzehnten Beispiel, basierend auf dem zehnten bis fünfzehnten Beispiel, umfasst Erfassungskomponente zur Ablaufverfolgung ferner einen gleichzeitigen Zugriff auf die gespeicherte Ablaufverfolgung und der zugehörigen Quellcodedaten für mehrere Benutzer.
In einem siebzehnten Beispiel, basierend auf dem ersten bis sechzehnten Beispiel, umfasst die Erfassungskomponente zur Ablaufverfolgung ferner das Anzeigen der Ablaufverfolgung und der zugehörigen Quellcodedaten in einer integrierten Entwicklungsumgebung (IDE).

Claims

Eine Erfassungskomponente zur Ablaufverfolgung zum Integrieren von Softwaretestskripten und zum Debuggen, ohne dass ein Benutzereingriff erforderlich ist, wobei die Erfassungskomponente zur Ablaufverfolgung umfasst: eine oder mehrere Verarbeitungsvorrichtungen, um den Status des Software-Test-Skripts zu empfangen ein oder mehrere Speichervorrichtungen, die Anweisungen speichern, die bei Ausführung durch ein oder mehrere Verarbeitungsvorrichtungen, die eine oder mehrere Verarbeitungsgeräte zu Folgendem veranlassen: ausführen eines Softwaretestskripts; und reagieren auf eine nicht erfolgreiche Ausführung des Software-Test-Skripts, wiederholen des Test-Skripts ohne Benutzereingriff; erfassen der Ablaufverfolgung und der zugehörigen Quellcodedaten der Ausführung des Testskripts ohne Benutzereingriff; und speichern der Ablaufverfolgung und der zugehörigen Quellcodedaten der Ausführung des Testskripts ohne Benutzereingriff.
Erfassungskomponente zur Ablaufverfolgung nach Anspruch 1, worin ein Status einen Fehler eines Tests darstellt.
Erfassungskomponente zur Ablaufverfolgung nach Anspruch 1, worin ein Status ein Timeout eines Tests darstellt.
Erfassungskomponente zur Ablaufverfolgung nach Anspruch 1, ferner umfassend: laden der gespeicherten Ablaufverfolgung und der zugehörigen Quellcodedaten zum Debuggen auf einer entfernten Entwicklungsumgebung.
Erfassungskomponente zur Ablaufverfolgung nach Anspruch 1, ferner umfassend: speichern und Zugreifen auf die Ablaufverfolgung und der zugehörigen Quellcodedaten aus einer Datenbank.
Erfassungskomponente zur Ablaufverfolgung nach Anspruch 1, ferner umfassend: speichern und Zugreifen auf die Ablaufverfolgung und der zugehörigen Quellcodedaten aus einer lokalen Entwicklungsumgebung.
Erfassungskomponente zur Ablaufverfolgung nach Anspruch 1, ferner umfassend: bereitstellen eines gleichzeitigen Zugriffs auf eine gespeicherte Ablaufverfolgung und der zugehörigen Quellcodedaten.
Erfassungskomponente zur Ablaufverfolgung nach Anspruch 1, ferner umfassend: anzeigen der Ablaufverfolgung und der zugehörigen Quellcodedaten in einer integrierten Entwicklungsumgebung (IDE).