FoxRunner

ist ein Automatisierungs- und Testtool für Visual FoxPro Anwendungen. Mit FoxRunner können Sie Ihre Visual FoxPro Anwendungen automatisch ablaufen lassen, für Tests, Demos, Schulung, Ergänzung zur Online-Hilfe, Automatisierung häufig wiederkehrender Aufgaben etc.

FoxRunner besteht aus einem Scripting-Modul mit Script-Recorder und Script-Runner, dem Testcode-Verfahren zur Durchführung von Unit-Tests auf Klassenebene und einem Datengenerierungs Tool, mit dem Sie automatisch Testdaten erstellen können.

Scripting für MS Visual FoxPro 5 und 6, z.B. für:

• Automatisierte Tests. Auch komplette Regressionstests werden durch Verwendung einmal erstellter Testscripts erstmals überhaupt machbar (=bezahlbar).
• Selbstlaufende Demos. Die Scripts können vom ersten lauffähigen Oberflächenprototyp bis zur komplett fertigen Anwendung beibehalten werden.
• Auto-Jobs, d.h. immer wiederkehrende Abläufe in Scripts hinterlegen. Der ausgebildete Kunde kann sich seine Scripts für Tagesabschlußläufe, Abruf von Auswertungen etc. sogar selbst erstellen.
• Lasttests und Multiusertests: Die Anwendung kann mit Hilfe von Scripts auf vielen Arbeitsplätzen gleichzeitig ablaufen, ohne daß jemand davor sitzen und sie bedienen müßte.
• Performance-Tests: Erstellen Sie Scripte, die bestimmte kritische Abläufe durchführen und gleichzeitig die benötigten Zeiten in einer Protokolldatei mitschreiben. So können Sie nach Tuning Maßnahmen leicht feststellen, was sich verschlimmbessert hat.
• usw. usf.

Highlights:

• Keine Änderung am Programmcode notwendig. Nur der Aufruf des ScriptRunners muß irgendwo in's Menü eingebunden werden.
• Script-Recorder zum interaktiven Aufzeichnen von sofort lauffähigen Scripts
• auch Clicks auf ActiveX Controls können vom ScriptRecorder aufgezeichnet und vom Script-Runner wiedergegeben werden
• öfter benötigte Abläufe können in Script-Procedures abgelegt werden
• Scripts für komplette Abläufe (z.B. Erfassen einer Rechnung) können separat aufgebaut und aus anderen Scripts heraus aufgerufen werden. Dadurch können Einzelscripts in einem oder mehreren Masterscripts zu kompletten Testdurchläufen zusammengefasst werden.
• Scriptsprache ist VFP, ergänzt um eigene, scriptspezifische Steuerungsfunktionen. Dadurch voller Durchgriff vom Script in die zu testende Applikation, um zum Beispiel Eigenschaften zu testender Objekte abprüfen zu können.
• Scriptfunktionen zur Erzeugung von Zufallswerten für:
• Strings
• Integer-Werte
• Ziffernfolgen
• numerische Werte
• jeweils mit Minimum/Maximum Angaben bzw.
einstellbarer Anzahl der Nachkommastellen
• Verfolgung des Script-Ablaufs über DEBUG OUTPUT möglich
• Erstellen und Editieren von Scripts mit dem VFP Sourcecode-Editor

Testcode:

Integriertes Verfahren zur Erstellung und Durchführung von klasseneigenen Tests. Der Testcode wird während der Entwicklung zum Unit Testing verwendet.

• vorbereitetete CEE Makros zur Erstellung des Testcodes
• Abruf des Testcodes eines Objektes aus der Entwicklungsumgebung
• Auswertung und Anzeige der vom Testcode zurückgelieferten Testergebnisse
• Anzeige aller testspezifischen Fehlermeldungen

Testdatenerstellung:

• Automatisches Erstellen von Testdaten
• Berücksichtigung der im DBC hinterlegten persistenten Relationen

Auf der Begleit-CD zu dieser Konferenz finden Sie ausführliche Beschreibungen zu den Bestandteilen von FoxRunner. FoxRunner ist ein Produkt der Firma

CAL
Computer Aided Logistics GmbH
Fallmerayerstr. 17

D-80796 München

Scripting mit FoxRunner

Der Script-Runner
Das Ziel

Es wird häufig gewünscht, Anwendungen vollautomatisch ablaufen zu lassen, sei es, um deren Funktionalität zu demonstrieren oder um häufig wiederkehrende, zeitaufwendige Tests durchzuführen. Auch zur Automatisierung von Aufgaben wie z.B. Aufruf von Tagesabschluß-Programmen, Ausgabe von Reports und so weiter, lassen sich Scripts sinnvoll einsetzen.

Für diese Zwecke wurde der in FoxRunner integrierte Script-Runner für Microsofts Visual FoxPro (VFP) entwickelt.

Der Script-Runner ermöglicht es, VFP Programme scriptgesteuert ablaufen zu lassen. Als Scriptsprache wird die normale Programmiersprache von VFP benutzt. Das hat zum einen den Vorteil, daß der VFP-Entwickler keine neue Sprache erlernen muß, um Scripts für seine Applikation zu schreiben. Zum anderen bietet der VFP Befehlsumfang hervorragende Möglichkeiten, Programme zu steuern, Programmsituationen abzufragen und darauf zu reagieren.

Die VFP Programmiersprache kann in den Scripts nahezu vollständig eingesetzt werden. Zusätzlich wurden einige Steuerbefehle implementiert, die weiter unten beschrieben werden. Scripts für den Script-Runner können mit Hilfe des ScriptRecorders interaktiv aufgezeichnet werden. Eine Beschreibung des Script-Recorders finden Sie in weiter unten.

Das Konzept

VFP bietet zur automatisierten Steuerung von Programmen als wichtigsten Befehl das KEYBOARD Kommando an, mit dem Zeichenfolgen oder Tastaturcodes an das Programm geschickt werden können, so als ob ein vor dem Bildschirm sitzender Benutzer diese eingegeben hätte. Die mit dem KEYBOARD Kommando abgeschickten Zeichen und Tastendrucke werden im Tastaturpuffer gespeichert und abgearbeitet, sobald VFP wieder auf Benutzereingaben wartet.

In diesem zeitverzögerten Abarbeiten der KEYBOARD Kommandos liegt ein Problem, das es weitgehend unmöglich macht, eine VFP Applikation durch ein einfaches VFP Programm zu steuern. Eine Sequenz von mehreren Programmzeilen wird dann nämlich nicht mehr unbedingt in der Reihenfolge abgearbeitet, in der sie angegeben ist. Aus diesem Grund ist der Script-Runner mit Hilfe eines Timerobjektes realisiert, daß sich automatisch in _SCREEN instantiiert. Alle Aktivitäten des Script-Runners sind in Methoden dieses Timers niedergelegt.

Script-Runner liest ein angegebenes Script zeilenweise ein. Bei jedem Timer-Tick wird eine Zeile des Scripts ausgeführt. Nach dem Ausführen einer Scriptzeile wird zunächst wieder die gesteuerte Applikation aktiv, die damit auf jedes KEYBOARD Kommando einzeln reagieren kann.

Da das Befehlsfenster in der VFP Entwicklungsumgebung den EventHandler ersetzt und somit das Pendant zu einem READ EVENTS innerhalb einer Applikation ist, können Sie den Script-Runner auch in der Entwicklungsumgebung aus dem Befehlsfenster heraus benutzen.

Der Script-Recorder

Der FoxRunner Script-Recorder dient dazu, Scripts für den Script-Runner interaktiv aufzeichnen.

Der Script-Recorder zeichnet die Tastatureingaben und Mouseclicks auf, die Sie zur Bedienung Ihres Programms vornehmen. Die Eingaben werden in Form von KEYBOARD oder MOUSE Kommandos in einem Script gespeichert. In vielen Fällen kann ein solches Script nach der Aufzeichnung sofort vom Script-Runner abgearbeitet werden. Da der Script-Recorder aber nur Eingaben erfassen kann, die von einem VFP-Programm direkt erkannt werden können, ist an der ein- oder anderen Stelle im aufgezeichneten Script eventuell eine manuelle Nacharbeit nötig.

Start des Script-Recorders

Starten Sie den Script-Recorder mit dem Menüpunkt FoxRunner -> Scripting -> Start Recording.

Der Script-Recorder gibt seinen jeweiligen Start/Stop Zustand in der Statuszeile des VFP-Screens aus.

Beenden mit Speichern des Scripts

Mit STRG+W (Write) beenden Sie die Aufzeichnung des Scripts. Die bis dahin aufgezeichneten Eingaben werden in eine Datei geschrieben, deren Namen vom Script-Recorder automatisch generiert wird. Alle automatisch generierten Scripts beginnen mit dem Aufzeichnungsdatum in der Form JJJJMMTT_ (Jahr, Monat, Tag) und der Zeit in der Form SSMMss (Stunde,Minute,Sekunde). Der Dateityp des Scripts ist .SCP.

Beenden ohne Speichern

Wenn Sie die Aufzeichnung des Scripts ohne Speichern abbrechen wollen, drücken Sie STRG+B (Break). Alle seit dem letzten Start oder Neustart des Script-Recorders aufgezeichneten Eingaben werden damit verworfen.

Mit STRG+R können Sie danach oder später die Aufzeichnung neu starten.

Unterbrechen der Aufzeichnung

Die Aufzeichnung kann mit STRG+S (Suspend) unterbrochen werden. Die seit dem letzten Start oder Neustart aufgezeichneten Eingaben bleiben erhalten, werden jedoch noch nicht gespeichert.

Mit STRG+R können Sie die Aufzeichnung zu einem beliebigen späteren Zeitpunkt fortsetzen.

Fortsetzen der Aufzeichnung

Mit STRG+R (Resume) setzen Sie eine unterbrochene Aufzeichnung fort.

Automatisierte Tests mit TESTCODE

Wieso sind Fehler à la "Variable XYZAutomatisierte Tests mit TESTCODE Wieso sind Fehler à la "Variable XY nicht gefunden!" die schlimmsten Fehler, die Ihr Kunde finden kann, wenn er Ihre Anwendung benutzt? Weil sie zeigen, daß die Anwendung nicht sorgfältig genug getestet wurde. Zumindest die Zeile des Codes, die den Fehler produziert, wurde nachweislich niemals durchlaufen. In jeder anderen Situation kann man argumentieren: "Tja, das ist eine isolierte Programmsituation, die nur unter sehr speziellen Bedingungen eintritt..." Ok, niemand ist in der Lage, jeden Weg, den eine Anwendung gehen könnte, auszutesten. Aber in einem sehr fundamentalen Sinn bedeutet "Testen", daß jede Zeile Code zumindest einmal durchlaufen wird.

Lassen Sie uns alle Fälle betrachten, die beim folgenden Stück Code getestet werden müssen:

IF nNumber = 0 nResult = 0 ELSE nResult = nValue / nNumber ENDIF IF nOtherNumber = 0 nOtherResult = 0 ELSE nOtherResult = nResult / nOtherNumber ENDIF

Für dieses einfache Stück Code werden vier Tests gebraucht:

• nNumber = 0
• nNumber <> 0
• nOtherNumber = 0
• nOtherNumber <> 0

Sie sehen, jedes IF in Ihrem Sourcecode generiert zwei neue Testfälle. Um den Algorithmus selbst zu prüfen, können weitere Testfälle notwendig werden. nNumber zum Beispiel kann kleiner oder größer Null sein, nOtherNumber kann Null sein während nNumber ungleich Null ist und umgekehrt.

Wie Sie sehen, gibt es eine Menge zu testen, nur um sicherzustellen, daß Ihr Kunde keine Syntaxfehler mehr findet, nachdem Sie Ihre Anwendung ausgeliefert haben. Und, schlimmer noch, bei jeder Änderung, die Sie an einer Funktion oder Methode durchführen, müssen alle möglichen Testfälle erneut überprüft werden. Das sollte man eigentlich einem Programm überlassen.

Die TESTCODE Methode

Die Idee ist recht einfach: Legen Sie in all Ihren Basisklassen eine Methode namens TESTCODE oder ähnlich an, zumindest aber in allen Basisklassen, aus denen Sie die Business-Objekte Ihrer Applikation ableiten. In dieser Testcode-Methode hinterlegen Sie den Code, der notwendig ist, um alle anderen Methoden der jeweiligen Klasse zu testen. Sie können die Testcode-Methode auf jeder Ableitungsebene ohne DoDefault() komplett überschreiben. Die Tests für die Methoden der Superklasse werden ja in der Testcode-Methode der Superklasse selbst hinterlegt und mit einem Objekt der Superklasse ausgeführt.

Die Struktur eines Testfalls

Alle Testfälle in der Testcode-Methode haben die selbe Struktur. Dies ist die allgemeine Struktur im Pseudo-Code:

IF MethodCall(Par1,Par2,…) <> ExpectedResult cTestResult = cTestResult + "test-specific error message" ENDIF

Die Methode, die getestet werden soll, wird mit den benötigten Parametern aufgerufen und die Rückgabe wird mit dem erwarteten Resultat verglichen. Wenn die Rückgabe dem erwarteten Resultat nicht entspricht, wird eine Fehlermeldung generiert und an die Variable cTestResult angehängt. Am Ende der Testcode-Methode wird cTestResult an das aufrufende Programm zurückgegeben. Wenn cTestResult leer ist, heißt daß, daß alle Tests erfolgreich durchgeführt werden konnten, wenn nicht, enthält cTestResult die Fehlermeldungen aller Tests, die schiefgegangen sind. Natürlich brauchen einige Testfälle etwas mehr an Vorbereitung, um durchgeführt werden zu können. Sie können diese Vorbereitungen vornehmen, bevor Sie die zu testende Methode aufrufen.

Ausführen des Testcodes

Es gibt verschiedene Wege, den in den Testcode-Methode hinterlegten Code ausführen zu lassen. Diese hängen unter anderem von der Struktur und dem Verhalten Ihrer Entwicklungsumgebung ab.

Das Ausführen des Testcodes wurde von uns in FoxRunner integriert. Dabei wird die Testcode-Methode eines ausgewählten Objekts aufgerufen und das Ergebnis des Testlaufs anzeigt. FoxRunner kann auch die TestCode Methoden von Objekten in einer Container-Hierarchie abrufen. Dazu werden alle Objekte der Container-Hierarchie daraufhin untersucht, ob sie eine TestCode Methode haben. Alle Ergebnisse der aufgerufenen TestCode Durchläufe werden zusammengefasst angezeigt.

Beispiel Testprotokoll

TestprotokollProjekt Komponente /Programmteil Version Nr. Datum des Tests getestet durch Testfall Nr.Kurzbeschreibung Status:E = ErsttestW = WiederholungstestR = Regressionstest TestplanAnforderung Nr. Soll-Ergebnis DurchführungScript Ist-ErgebnisBewertung:0 = OK1 = Schönheitsfehler2 = gravierender Fehler3 = Absturz o.ä. Bearbeitung DatumBearbeiterKommentarStatus *

* Bearbeitungsstati: WPwird geprüft IAin Arbeit OKerledigt (bitte Version angeben) NNnicht nachvollziehbar NEkein Fehler, Benutzerfehler oder ähnliches ÄNProgrammänderung erforderlich

Beispiel Testprotokoll

Bearbeitung

* Bearbeitungsstati:

WP          wird geprüft

IA            in Arbeit

OK          erledigt (bitte Version angeben)

NN          nicht nachvollziehbar

NE           kein Fehler, Benutzerfehler oder ähnliches

ÄN          Programmänderung erforderlich