Ein starkes Duo: Testdesign und Testautomatisierung am Beispiel

Artikel von Maike Uhlig und Peter Preintner

Ihr „Aha!“-Moment ist unser Ansporn

Im Projektalltag begegnen wir vielen Kollegen, die bereits von Testautomatisierung gehört haben. Eine kleinere Gruppe von ihnen hat sich ebenfalls mit den Methoden und Werkzeugen der Testautomatisierung in der Theorie auseinandergesetzt. So weit, so gut. Häufig kommt aber nur ein Bruchteil der Kollegen in den Genuss, die Testautomatisierung an einem konkreten Projektbeispiel nachzuvollziehen bzw. selbst aktiv mitzugestalten. Die Mehrzahl der Kollegen nimmt somit Testautomatisierung nur als ein theoretisches Konstrukt wahr, dessen praktische Anwendung sogenannten Testautomatisierungsexperten vorbehalten bleibt.

Kennen Sie diese Situation oder fühlen Sie sich sogar als einer dieser Kollegen angesprochen? Wenn ja, so sind Sie genau unsere Zielgruppe. Denn wir wollen diese Wahrnehmung korrigieren, indem wir Ihnen die Testautomatisierung an einem konkreten Projektbeispiel näherbringen.

Was Sie in diesem Artikel erwartet

Anhand eines Projektbeispiels wollen wir symbolisch eine Brücke bauen, die das Ufer der theoretischen Abhandlungen zur Automatisierung von Testfällen mit der anderen Seite ihrer Implementierung verbindet. Der zu überbrückende Fluss soll der Strom der Erkenntnis sein, den Sie von der Brücke aus beobachten und studieren können. In diesen Fluss werfen wir unsere gesammelten Erfahrungen zur Implementierung eines Testautomatisierungsrahmenwerks und dessen Zusammenspiel mit dem Testdesign.

Wenn Sie nach dem Lesen des Artikels den Übergang von Theorie zur Praxis in der Testautomatisierung nachvollziehen konnten und Sie das Zusammenspiel von Testfallerstellung im Testdesign und zugehörigen Aufrufskripten in der Testautomatisierung verstanden haben, so gratulieren wir Ihnen zu Ihrem persönlichen „Aha!“-Moment! Dann haben wir unsere Sache gut gemacht.

Erwartungen an den Leser

Was erwarten wir von unseren Lesern? Von ihnen erwarten wir, dass sie Erfahrung in der Testfallerstellung und manuellen Testdurchführung mitbringen. Darüber hinaus kennen unsere Leser die generelle Zielstellung von Testautomatisierung und zumindest deren theoretische Einsatzmöglichkeiten in der Praxis. Weiterhin werden die datengetriebene und schlüsselwortgetriebene Vorgehensweise und deren Kombination bei der Erstellung eines Testautomatisierungsrahmenwerks als bekannt vorausgesetzt. Grundlegende Programmierkenntnisse sind unerlässlich, um die enthaltenen Codebeispiele in diesem Artikel nachvollziehen zu können. Erfahrungen mit konkreten Testautomatisierungs- und Testmanagementwerkzeugen werden nicht vorausgesetzt.

Sind Sie weiterhin dabei? Oder stoßen Sie gerade ab hier dazu? Dann folgen Sie uns bitte! Wir hoffen, wir sehen Sie am Ende des Artikels auf der Mitte unserer Brücke über dem Fluss der Erkenntnis zum Zusammenspiel von Testdesign und Testautomatisierung wieder.

Let’s go!

Das Projektbeispiel

In unserem Projektbeispiel geht es um eine browsergestützte Bankenanwendung mit angeschlossener Datenbank (entspricht der „Software under Test“ (SUT) in Abbildung 1). Diese Anwendung verwaltet die Kredite zur Finanzierung von Fahrzeugen, und zwar sowohl für deren Produktion (Herstellerkredite) als auch für deren Einkauf (Händlerkredite). Die Anwendung wird stetig aktualisiert. Pro Jahr sind zwei Major Releases und mehreren Minor Releases geplant. Ein Testzyklus dauert zwischen 2 und 4 Wochen, dessen Laufzeit hängt von der Release-Größe ab. Der Anteil an Regressionstests pro Release beträgt ca. 60–80 % bei einem Gesamtvolumen von ca. 800 Regressionstestfällen.

Die Testfälle lagen zu Projektbeginn in Word-Dokumenten vor, und ihre Anzahl lag bei über 1.000. Ein Ziel des Projektes war es, diese Testfälle zu prüfen und alle relevanten Testfälle in das Testmanagementwerkzeug TestBench von Imbus zu überführen. Dieses Werkzeug ermöglicht es dem Tester, die einzelnen Testschritte in wiederverwendbaren Bausteinen (sogen. Interaktionen) samt benötigten Daten abzulegen und daraus neue Testfälle per Drag & Drop zusammenzustellen. Die Testfallerstellung erfolgte damit systematischer und vor allem schneller.

Um nun die Tester von sich wiederholenden und manuell auszuführenden Tests pro Release zu entlasten, wurde für die Automatisierung der spezifikationsorientierten Tests (Blackbox Tests) das Werkzeug TestComplete von SmartBear Software verwendet. Als Integrationslösung für den Zusammenschluss von TestBench und TestComplete wurde der iTEP Wrapper verwendet. Der iTEP Wrapper bildet hierbei das Bindeglied zwischen formalem Testdesign und dem Automatisierungscode.

Besonders hilfreich sind automatisierte Testdurchläufe in der Anfangsphase eines Testzyklus, wo die neue Softwarelieferung überblicksartig (Smoke Tests) und im Detail (Base Tests) auf ihre Kernfunktionalitäten und die neu implementierten Features hin überprüft wird. Somit kann man zu Beginn eines Testzyklus schon innerhalb der ersten Stunden nach Ausführung der Smoke Tests beurteilen, ob die aktuelle Softwarelieferung überhaupt „gut genug“ ist, um im Detail und in ihrem vollen Umfang getestet zu werden.

Nach erfolgter Automatisierung der Testfälle entstehen in unserem Projektbeispiel für den Tester aktuell nur noch folgende Aufwände während der Testdurchführung (entspricht der Außensicht in Abbildung 1):

1. Die Testfallbeschreibungen mithilfe des Testmanagementwerkzeugs zu exportieren, wobei ein gezipptes XML-Dokument entsteht,

2. die Exportdatei in ein dediziertes Verzeichnis ablegen, z. B. P:\…\TestAutomation\ TestumgebungXYZ\ZyklusN\TestBenchExports,

3. das Testautomatisierungsframework liest die Datei aus dem Verzeichnis und führt die enthaltenen Testfälle mit Testschritten automatisch aus,

4. die Testergebnisse der automatisierten Testdurchführung aus einem anderen dedizierten Verzeichnis abholen (z. B. P:\…\ TestAutomation\TestumgebungXYZ\ZyklusN\ Ergebnisse) und in das Testmanagementwerkzeug importieren.

Sie fragen sich eventuell in diesem Moment, wie man in den zuvor beschriebenen Idealzustand gelangt. In den folgenden Abschnitten blicken wir hinter die Kulissen (entspricht der Innensicht in Abbildung 1). Es wird das Testautomatisierungsframework vorgestellt und dessen Schnittstelle zum Testmanagementwerkzeug. Das Zusammenspiel von Testdesign und Testautomatisierung wird an einem durchgehenden Beispiel verdeutlicht.

Die Testfallspezifikation als XML-Export

Gegenstand der Testautomatisierung ist der zu automatisierende Testfall. In unserem Projektbeispiel sind die Testfälle im Testmanagementwerkzeug abgelegt. Die einzelnen Testschritte sind durch formal definierte Schlüsselwörter mit Bezug zu Objekten an der Benutzeroberfläche beschrieben.
Beispiel: Der folgende Anwendungsfall „Anlegen eines Finanzierungsvertrages für ein Fahrzeug“ wurde innerhalb der TestBench als Testfall mit den verfügbaren Testbausteinen (auch Testelemente genannt) beschrieben.

Der Testfall beinhaltet an Testschritten (auch Interaktionen genannt) u. a. die folgende Anweisung für den Tester:

enter Fahrgestell Nr (vehicle identification number)

Ein so erstellter Testfall wird mittels XMLExport als gezippte Datei der Testautomatisierung zur Verfügung gestellt. Der Export zu unserem Anwendungsfall schaut in Auszügen zur obigen Anweisung aus wie in Abbildung 2 dargestellt. An anwendungsfallbezogenen Nutzdaten findet man in diesem XML-Export die obige Anweisung mit folgenden Angaben wieder:

Parameter und Wert sind jeweils als Arrays definiert, so dass eine Interaktion mehrere Parameter und Werte enthalten kann. Die Anweisung zur Eingabe einer Fahrgestellnummer bedeutet übertragen auf die zu testende Bankanwendung, dass der Tester im Browser in ein Textfeld mit der Bezeichnung Fahrgestell Nr eine beliebige 17-stellige Fahrzeugidentifikationsnummer eintragen soll. In diesem Beispiel wird das Eintragen einer beliebigen Fahrzeugidentifikationsnummer durch den Wert „<any value>“ ausgedrückt. Im Testdesign könnte hier aber auch ein konkreter Wert definiert werden.

1. <itb-export-report>
2.   <test-case id=“4611686020000008546″ uid=“CP-TC-560″>
3.     <name>Vehicle contract creation</name>
4.     <path>/Contract Management/Contract Creation (CC)/CC with model search       </path>
5.     <specification>
6.       <description>Creates a new contract</description>
7.     </specification>
8.     <UserDefinedFields>
9.       <UserDefinedField label=“smoketest“ value=“true“/>
10.       <UserDefinedField label=“basic test“ value=“false“/>
11.     </UserDefinedFields>
12.     <actions-and-reactions>
13.       <metawordCall id=“2305843010000039670″ uid=“CP-IA-1409″ name=“enter         Fahrgestell Nr“ path=“Bank.TeilA.Interaktion.Simple.enter“         signature=“Bank.TeilA.Interaktion.Simple.enter.enter Fahrgestell Nr         (vehicle identification number)“>
14.         <description>Enter a unique vehicle identification number in the field
[Fahrgestell Nr.]; with a required length of 17 (alphanumeric).
</description>
15.         <parameter name=“vehicle identification number“/>         <parameter datatype=“vehicle identification number“                    path=“Bank.Common.Datatypes.Simple“                    name=“vehicle identification number“>
16.           <value>vehicle identification number</value>
17.           <description>In menu [Objekt], section [Details], tab [Objekt],             text field [Fahrgestell Nr.].</description>
18.         </parameter>
19.       </metawordCall>
20.     </actions-and-reactions>
21.     <data-and-parameter>       <parameter index=“18″ datatype=“vehicle identification number“

             uid=“CP-DT-620″ path=“Bank.Common.Datatypes.Simple“ version=““

             name=“vehicle identification number“>

                   </parameter>
22.     </data-and-parameter>
23.     <tc-spec-param-properties>
24.       <parameter index=“18″ name=“vehicle identification number“>
25.         <equival-class>valid VIN</equival-class>
26.         <representative><any value></representative>
27.         <references/>
28.       </parameter>
29.     </tc-spec-param-properties>
30.     […] 31. </itb-export-report>

Abbildung 2

Die Automatisierung der Testfallspezifikation

Teil 1: Der iTEP Wrapper

Die automatisierte Testdurchführung einer Testfallspezifikation wird durch den Aufruf des sogenannten iTEP Wrappers gestartet. Der iTEP Wrapper ist Bestandteil der TestBench und umfasst Codefragmente zur Überprüfung der XML-Exporte. So liest der Wrapper u. a. zusätzliche Verwaltungsinformationen (z. B. Ausführungsmodus – Smoke Test/Base Test) zu einer Testfallspezifikation aus.

Während der Wrapper einen XML-Export einliest, gibt er jede aufzuführende Interaktion (Action) einzeln an die Automatisierung weiter. Nach der Bearbeitung einer Interaktion schreibt er das Ergebnis in das Testprotokoll zurück.

Ebenso überprüft der Wrapper die Informationen während der Durchführung einer Interaktion (z. B. <skip it> als Hinweis, einen Testschritt zu überspringen) und die Statusinformationen auf Testfallebene (z. B. failed). Um flexibler bei der automatisierten Abarbeitung eines Testfallsatzes zu sein, sind für verschiedene Prüffunktionen zusätzlich temporäre Wrapper implementiert. Diese Wrapper ermöglichen es, während eines Testlaufs mittels einer temporären Wrapper-Instanz nachfolgende oder vorausgehende Interak
tionen und deren Daten abzufragen und zu prüfen. So kann beispielsweise mithilfe einer temporären Wrapper-Instanz festgestellt werden, ob ein Testfall überhaupt automatisiert ausgeführt werden darf, indem alle verfügbaren Statusinformationen zuvor ausgewertet werden.

Teil 2: Struktur der Skriptsammlung und Namenskonvention für Skripte

Als Vorlage für die Strukturierung der einzelnen Automatisierungsskripte dient die GUI der Bankanwendung (siehe Software under Test in Abbildung 1). Jede Maske in der Benutzeroberfläche wird in einem eigenen Automatisierungsskript (auch Aufrufskript) abgelegt.

Beispielsweise gibt es innerhalb der Bankanwendung die Funktion, ein Objekt (z. B. Motorrad) zu finanzieren. Dafür wird ein Aufrufskript TeilanwendungA_ObjektFinanzieren_Objekt (Benennungsschema: <Anwend ungsname>_<Maskenname>_<Submaske/Karteireiter>) angelegt, wobei das letzte _Objekt im Skriptnamen einen konkreten Karteireiter innerhalb der Gesamtseite der Anwendung beschreibt.

Dieses Benennungsschema dient zur Wahrung der Übersichtlichkeit, da einige Masken innerhalb der Anwendung sehr umfangreich sind und für jedes grafische Steuerelement eigene Interaktionsaufrufe und Programmschritte ausgeführt werden müssen.

Teil 3: Die globale Projektvariable CurrentGuiScript

Während der automatisierten Ausführung eines Testfalls loggt das Testautomatisierungsframework parallel die Information mit, in welcher Maske der zu testenden Teilanwendung der aktuelle Testschritt ausgeführt werden soll.

Hierzu wurde eine globale Projektvariable CurrentGuiScript definiert. Sie entspricht dem „Wo befinde ich mich in der Anwendung“ und bestimmt, welches GUI-Element mit der nächsten Interaktion aufzurufen ist. Diese Information über den Kontext, in dem sich der Ablauf befindet, ist notwendig, da oft dieselben Interaktionsbeschreibungen im Testdesign für mehrere GUI-Masken verwendet werden. So kommt in unserem Beispiel die Interaktion „enter Fahrgestell Nr“ sowohl in Masken der Fahrzeuganlage als auch in Suchmasken der Fahrzeuge zum Einsatz. Initialisiert wird die Variable CurrentGuiScript mit dem Wert des Skriptnamens, der für die Maske zuständig ist, welche die Anwendung zum Start präsentiert. Im weiteren Verlauf des Tests wird die Variable immer wieder aktualisiert, z. B. beim Anwählen eines verdeckten Reiters oder beim Klicken auf einen Link. Das heißt, jede Interaktion, die zum Wechsel auf eine andere GUI-Maske führt, aktualisiert automatisch die Projektvariable CurrentGuiScript. Dies geschieht in der zu einer Interaktion hinterlegten Methode, welche den Aufruf für den Seitenwechsel ausführt.

Teil 4: Der Controller

Der iTEP Wrapper reicht eine auszuführende Interaktion – in unserem Beispiel die Interaktion enter Fahrgestell Nr (vehicle identification number) – in Form eines Skriptaufrufs an den sogenannten Controller weiter. Der Controller selbst stellt wiederum ein Skript dar, das den eigentlichen Skriptaufruf für die automatisierte Ausführung der Interaktion steuert.

Die folgenden Steuerinformationen stehen hierbei dem Controller zur Verfügung:

  • Aktion, Parameter und Werte der auszuführenden Interaktion
  • Durch Auslesen der Projektvariable CurrentGuiScript weiß der Controller, in welcher Teilanwendung und innerhalb welcher Maske der aktuelle Testschritt ausgeführt werden soll (z. B. CurrentGuiScript = „TeilanwendungA_ObjektFinanzieren_Objekt“).

Durch Stringkonkatenation erstellt der Controller anschließend folgenden Funktionsaufruf immer nach demselben Muster und übergibt diesen an das eigentliche Ausführungsskript:

String funcCall = CurrentGuiScript +
„.callFunction(action, parameters, values)“;
eval(funcCall);

Mittels der Methode eval() wird dem der Variable funcCall zugewiesene String (Zeichenkette) ausführbarer Code zugeordnet. Der Controller leitet den somit erstellten Aufruf an das jeweilige Automatisierungsskript weiter, in dem eine Methode callFunction()
enthalten ist. In dieser Funktion erfolgt das Mapping der ursprünglichen Interaktion auf die zugehörigen automatisiert ausführbaren Schritte (Methoden). Je nach Interaktion sind bei einem Aufruf ein oder mehrere Schritte nötig.

Sollte sich einmal die Bezeichnung für eine Interaktion im Testdesign innerhalb der TestBench ändern, so muss im jeweiligen Automatisierungsskript nur der Name für das Mapping (also der Interaktionsname) abgeändert werden, ohne dass die Methodennamen und die zugehörigen Aufrufe ebenfalls angepasst werden müssen.

Teil 5: Vereinheitlichte Handhabung der verschiedenen GUIElemente

Für die Handhabung der verschiedenen Benutzerinteraktionen innerhalb der GUI wird ein Skript GUI zur Verfügung gestellt, welches für jeden GUI-Elementtyp (z. B. DropdownListe) innerhalb der Bankanwendung entsprechende Funktionen zu deren Handhabung implementiert.

Dieses Skript wurde eingeführt, um etwaige Platzhalter und Sonderfälle für Eingaben zentralisiert abhandeln zu können und Verhaltenseigenarten nicht in jedem Aufruf separat implementieren zu müssen. Die callFunction() verwendet diese GUI-Funktionen zum Abarbeiten der Interaktionen, wobei benötigte Parameter, Kommandos für Sonderfälle und verschiedene Verhaltensarten mit übergeben werden.

Teil 6: Kleine Helferlein

Helper

Um die verschiedenen Logs nicht quer über das Projekt zu verstreuen, wird ein weiteres Skript benutzt. Eine sogenannte Helper-Klasse implementiert generelle Hilfsfunktionen, welche von vielen Aufrufskripten benötigt werden. Mittels der Helper-Klasse können zum Beispiel Testdaten zwischengespeichert werden, um u. a. Abhängigkeitsbeziehungen zwischen den Testdaten zu überprüfen.

Events

Mithilfe der Events-Klasse können allgemeine TestComplete-Events erweitert werden (z. B. Rücksetzen von Variablen, Einstellung Log Level, Test anhalten).

BrowserController

Mittels der Klasse BrowserController werden weitere Hilfsfunktionen wie Identifikation, Initialisierung, Steuerung und Schließen eines Webbrowsers zur Verfügung gestellt.

Bis hierher wurden nun alle Komponenten und Schnittstellen des Testautomatisierungsrahmenwerks vorgestellt. Im nächsten Absatz begegnen wir den Komponenten am praktischen Beispiel wieder.

Ablauf der automatisierten Abarbeitung der Beispielanweisung

Die Verwendung der Komponenten des Testautomatisierungsrahmenwerks und das Zusammenspiel von Testdesign und Testautomatisierung wird an der Beispielanweisung enter Fahrgestell Nr (vehicle identification number) veranschaulicht.

Die Anweisung selbst stellt einen auszuführenden Testschritt in einem Testfall dar und wird mit den Testbausteinen der TestBench erstellt. Der Testschritt beinhaltet die auszuführende Interaktion enter Fahrgestell Nr. Dieser Testbaustein ist ein Umsetzungsbeispiel für die schlüsselwortgetriebene Vorgehensweise bei der Automatisierung von Testfällen.

Die Interaktion enter Fahrgestell Nr beinhaltet wiederum einen Testbaustein, und zwar den Datentyp vehicle identification number, der als Behälter für eine konkrete Fahrzeugidentifikationsnummer während der Testausführung dient. Dieser Testbaustein ist ein Umsetzungsbeispiel für die datengetriebene Vorgehensweise bei der Automatisierung von Testfällen.

Wie der gesamte Testbaustein aus Interaktion und Daten von der Testautomatisierung verarbeitet wird, soll anhand von Codefragmenten aus dem Testautomatisierungsrahmenwerk dargestellt werden.

Schritt 1: Der iTEP Wrapper liest den Testfall aus der TestBench aus (XML-Export) und reicht die Interaktionsnamen (Actions) samt Parameter und Werten an die Klasse Controller weiter.

1. /* class: ITEP_WRAPPER
2. A call from TextExecute starts this script. It gets the actions from the TestBench exports and gives them to the executing scripts. */
3.
4. function ITEPMainLoop() {
5.   […]
6.   Controller.ExecuteTestStep(     action, parameters, values);
7.   […]
8. }

Schritt 2: Der Controller führt einen Testschritt (Interaktion) aus. Die globale Projektvariable CurrentGuiScript hält vor, wo in der Anwendung sich die Automatisierung befindet. Der Controller steuert, welches Skript mit der angefragten Interaktion aufgerufen wird. Jedes Aufrufskript besitzt genau eine Methode callFunction().

1. /* class: Controller
2. It is a mediator between the class ITEP_Wrapper and the scripts which process the actions. */
3.
4. function ExecuteTestStep(   action, parameters, values) {
5.   […]
6.   Project.Variables.     CurrentGuiScript =     „TeilanwendungA_     ObjektFinanzieren_Objekt“;
7.   String ScriptCall = Project.     Variables.CurrentGuiScript +     „.callFunction(action,     parameters, values)“;
8.   var Error = eval(ScriptCall);     // Evaluierung des erstellten String
9.   […]
10. }

Schritt 3: Innerhalb des gefundenen Aufrufskriptes wird die Interaktion aus dem XML-Export auf die Automatisierungslogik gemappt und letztendlich in der GUI automatisch ausgeführt (s. Abb. 3).

Switch-Case-Anweisungen kennen die Interaktionsnamen und rufen über das ObjektMapping von TestComplete (Aliases) das konkrete GUI-Element auf und wählen dort Einträge aus oder setzen Texte etc.

Ändert sich der Interaktionsname, so muss hier nur der Name in der Case-Anweisung geändert werden. Alle Methodennamen, Skriptaufrufe und Objekt-Mappings bleiben unverändert. Um alte und neue Interaktionsnamen zu unterstützen, können auch Mehrfacheinträge in der Case-Anweisung eingetragen werden. Da es sich um Skripte handelt, kann man mittels Textsuche leicht die Aufrufskripte ermitteln, in denen ein zu ändernder Interaktionsname verwendet wurde.

Wird mit einer Interaktion in eine andere Maske navigiert, setzt das Aufrufskript die globale Projektvariable CurrentGuiScript für den nächsten Skriptnamen, so dass der Controller beim nächsten Aufruf einer Interaktion wieder weiß, mit welchem GUI-Skript diese auszuführen ist.

In jedem dieser Automatisierungsskripte (GUI-Skript) sind die Interaktionen zusammengefasst, die an einer bestimmten Stelle innerhalb der GUI der Bankanwendung ausgeführt werden können.

Last but not least: Die Ermittlung von Testdaten

In den zu automatisierenden Testfällen werden häufig Platzhalter für die konkrete Ausprägung von Testdaten verwendet (z. B. <any value> für eine gültige Händlernummer). Um während der Testdurchführung diese Platzhalter durch konkrete Testdaten ersetzen zu können, wurden zur Erhebung dieser Testdaten eine Datenbankanbindung in die Testautomatisierung integriert und ein Webservice für die Datenbankanfrage implementiert.

1. /* class: TeilanwendungA_Vertragsanlage */
2. //Innerhalb des Automatisierungsskripts TeilanwendungA_ObjektFinanzieren_Objekt
3.
4. function callFunction(action,   parameters, values) {
5.   try {
6.     switch (action) {
7.       […]
8.       case „enter_Fahrgestell_Nr“:{
9.         if (new String(values[0]).indexOf(„empty“) == -1) {
10.           if (Helper.checkIfAnyValueRequested(new String(values[0])))
11. Gui.insertIntoTextbox(Aliases.Bank.TeilanwendungA.Objekt_ finanzieren_Tab_Objekt.Fahrgestellnr, Helper.generateCarSerial(), false);
12.           else
13. Gui.insertIntoTextbox(Aliases.Bank.TeilanwendungA.Objekt_ finanzieren_Tab_Objekt.Fahrgestellnr, values[0], false);
14.           }
15.         break;
16.       }
17.       […]
18.     }
19.   }
20.   catch(exception) {
21.     Logging.log(2, exception.message, action);
22.     return;
23.   }
24. }

Abbildung 3

Während der Testdurchführung werden bei Bedarf die jeweiligen Datenbankanfragen (SQL Statements) auf den Test-Clients automatisch generiert und als Webservice-Anfrage an einen zentralen Server weitergeleitet. Dieser holt die benötigten Daten aus der Datenbank und gibt sie an den jeweiligen Aufrufer zurück.

Resultierend aus der automatisierten Testdatenermittlung wurde bei dieser Gelegenheit auch eine Oberfläche für den Webservice geschaffen, über welche Tester im Rahmen manueller Tests selbst geeignete Testdaten schnell aus der Datenbank auf Basis des aktuellen Testdatenbestandes ermitteln können und sich somit die zeitaufwendige Suche innerhalb der Bankanwendung ersparen.

Zusammenfassung

Anhand eines konkreten Projektbeispiels haben wir Ihnen das Zusammenspiel von Testdesign und Testautomatisierung aufgezeigt. Die Bestandteile unseres Testautomatisierungsframeworks haben wir Ihnen vorgestellt. Wenn das Testdesign und die Testautomatisierung aufeinander abgestimmt sind, dann ist es ein starkes Duo, das Ihre manuellen Testaufwände um ein Vielfaches reduziert.

Die Verwendung von Schlüsselwörtern in Testdesign und Testautomatisierung, wie wir sie dargestellt haben, ermöglicht es Testdesignern, neue Testfälle und Interaktionsabläufe für die aktuelle Anwendung zu erstellen, die automatisch ausgeführt werden können, ohne dass dafür neuer Automatisierungscode geschrieben werden muss.

Danksagung

Wir bedanken uns bei den Mitarbeitern der Firmen MaibornWolff und Special Software Solutions – alles ausgewiesene IT-Experten in Testdesign, Test, Testautomatisierung und Testmanagement –, die im vorgestellten Projekt bei der Konzeption und Umsetzung des Testautomatisierungsrahmenwerks sowie als Inputgeber bei diesem Artikel mitgewirkt haben.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Kategorien

Recent Posts