Software-Test / Testautomatisierung

SAP Testautomatisierung – plattformübergreifender Test mit JCo 2/2

In Teil 1 dieses Artikels haben wir Java und JCo soweit gebracht, dass eCATT-Skripte zur SAP Testautomatisierung von außen gestartet werden können. Was jetzt noch fehlt, ist Einfluss auf die Skripte zu nehmen, Informationen mitzugeben und auszulesen. Um das hinzukriegen müssen wir uns einiger Kniffe bedienen und etwas tiefer in technische Gefilde abtauchen. Hierum dreht es sich im zweiten Teil.

 

Unser Problem aus Teil 1: wie spielen wir über Bande und wie durchbrechen wir Hindernisse?

Unser Problem aus Teil 1: wie spielen wir über Bande und wie durchbrechen wir Hindernisse?

 

Einerseits…

Wie im letzten Teil beschrieben kann man auf direktem Weg keine Parameter über JCo in das eCATT-Skript schreiben. Arbeitet man sich durch die Import Parameter von ECATT_EXECUTE durch, stößt man jedoch bald auf die JCoTable IT_VAR_EXT. Mit dieser kann ein externes Variantenfile definiert werden. Ein eCATT-Testskript kann mit diesem File nicht umgehen, wohl aber eine Testkonfiguration.

Banane_SAP Testautomatisierung

… einerseits …

Um Missverständnisse zu vermeiden werden ab hier die Bezeichnungen JCo Import/Export Parameter und eCATT Import/Export Parameter verwendet: erstere werden von JCo gelesen bzw. ausgegeben, unabhängig davon, ob man wie in diesem Artikel ECATT_EXECUTE oder einen völlig anderen RFC verwendet. Letztere sind die Parameter, die das eCATT-Skript selbst verwendet.

Der erste Impuls ist es nun, um unser eCATT-Skript eine Testkonfiguration zu stricken und diese via JCo aufzurufen (man muss dazu im Parameter TO_EXECUTE den Object Type OBJ_TYPE auf ECTC für ECatt Test Configuration ändern). Diese Testkonfiguration soll ihre eCATT Import Parameter aus dem in IT_VAR_EXT definierten Variantenfile beziehen. Das funktioniert zwar, allerdings muss man sich für die eCATT Export Parameter dann immer noch etwas anderes überlegen, da man diese Parameter nicht auf demselben Weg zurückgeben kann. Daneben müsste auch um jedes eCATT-Testskript herum eine Testkonfiguration erstellt werden, ein zusätzlicher Aufwand, von dem wir – abgesehen von den eCATT Import Parametern – aus Sicht des Java Frameworks keinen Nutzen haben.

 

Andererseits…

Also was tun? Eine Auflistung aller Export Parameter befindet sich im eCATT Testprotokoll. Könnte man dieses exportieren und auslesen, würde man auch an die eCATT Export Parameter herankommen. Außerdem ist das Protokoll an sich eine hilfreiche Informationsquelle, falls etwas schief läuft und man auf Fehlersuche gehen muss.

Karotte_SAP Testautomatisierung

… andererseits …

Man kann Testprotokolle in der Tat exportieren, wenngleich SAP diese Funktion gut versteckt hat. Öffnet man die Druckvorschau für das Testprotokoll, kann man es mit einem Befehl in den Tiefen der Menüleiste als lokale Datei abspeichern. Zuvor sollte man noch alle Knoten expandieren, so dass die eCATT Export Parameter auch wirklich mit abgespeichert werden. Als Dateiformat wählt man das Textformat; so lässt sich die Datei am Leichtesten parsen und die Parameter extrahieren.

Das Schreiben eines Parsers in Java wird in diesem Artikel nicht näher beschrieben (im Netz finden sich hierzu zahlreiche Informationen). Wie aber exportiert man das Testprotokoll automatisch nach Ausführung des eCATT Skripts? Hier hilft einem die nahtlose Integration von eCATT in SAP: eCATT selbst ist letztendlich auch nur eine SAP Transaktion (SECATT) und kann somit mit einem eCATT Skript automatisiert werden.

Die eCATT-Protokoll-ID ist eine der wenigen Informationen, die man von JCo direkt bekommt. Man könnte also nach dem ersten eCATT-Testskript ein zweites Skript starten, das die Protokoll-ID als Import Parameter erhält und mit dieser das Testprotokoll des Ersten einsammelt. Das funktioniert, es geht aber noch ein Stück eleganter.

 

Also…

ObstUndGemueseTanz

… also!

Das zweite Skript kümmert sich nicht nur um das nachträgliche Einsammeln der Informationen, sondern auch um die Ausführung des eCATT-Testskripts. Es wählt in SECATT das richtige eCATT-Testskript aus, setzt seine Import Parameter (ist man erst in der Testskript-Ausführung ist, kann dies on-the-fly geschehen) und startet es. Das zweite Skript wird erst fortgesetzt, nachdem das Testskript durchgelaufen ist. Praktischerweise wird dann bereits das gewünschte Testprotokoll angezeigt, so dass dieses direkt lokal abgespeichert werden kann.

 

Rekursion: eCATT selbst kann mit eCATT ebenfalls automatisiert werden

Rekursion: auch eCATT selbst kann mit eCATT automatisiert werden

 

Das zweite Skript umschließt das eCATT-Testskript nun vollständig und steuert sowohl die Ausführung als auch das Beschaffen der Ergebnisse. Es muss nur ein einziges Mal geschrieben werden und kann dann für jedes Testskript genutzt werden. Aufgrund seiner Wichtigkeit und Nützlichkeit erhält es auch einen eigenen Namen: eCATT-Metaskript.

 

One script to rule them all: das eCATT Metaskript

Der prinzipielle Aufbau aus dem letzten Artikel mit JCo, Destinationfile und ECATT_EXECUTE bleibt gleich, mit folgenden Modifikationen:

Die Destination verweist immer zum Solution Manager, denn wenn das Metaskript und alle weiteren Testskripte dort liegen, erleichtert das die Wartung ungemein. Das Account im Destinationfile benötigt lediglich Rechte zum Ausführen von existierenden eCATT-Testskripten und Testkonfigurationen. Zum Bearbeiten und Erweitern von Skripten verwendet der Testautomatisierer einen eigenen Account mit entsprechenden Privilegien. Dieser muss nicht mit Passwort im Destinationfile stehen, was auch die Sicherheit erhöht.

Einmalig wird ein Systemdatencontainer mit Verbindungsdaten für alle zu testenden SAP-Systeme erstellt. Das eCATT-Metaskript kann beim Ausführen des eCATT-Testskripts on-the-fly die Verbindung zum richtigen System auswählen. Damit werden trotz zentraler Skripteverwaltung alle Systeme für die SAP Testautomatisierung erreichbar.

Über JCo wird ab nun ausschließlich das eCATT-Metaskript aufgerufen. Allerdings nicht direkt, denn irgendwie müssen die eCATT Import Parameter ja doch noch in SAP gelangen. Und das ist nur über ein Variantenfile und eine Testkonfiguration möglich. Also erstellt man einmalig für das eCATT-Metaskript Z_TS_METASKRIPT eine Meta-Testkonfiguration Z_TK_METAKONF und trägt diese in seinen Code ein:

JCoTable TO_EXECUTE = ecattExecute.getExportParameterList().getTable("EXECUTED");
TO_EXECUTE.appendRows(1);
TO_EXECUTE.nextRow();
TO_EXECUTE.setValue("OBJ_TYPE", "ECTC");
TO_EXECUTE.setValue("OBJ_NAME", "Z_TK_METAKONF");
ecattExecute.getImportParameterList().setValue("TO_EXECUTE", TO_EXECUTE);

 

Das Variantenfile enthält alle eCATT Import Parameter, sowohl für das Metaskript als auch das Testskript. Es wird eingebunden mit:

JCoTable IT_VAR_EXT = ecattExecute.getImportParameterList().getTable("IT_VAR_EXT");
IT_VAR_EXT.appendRows(1);
IT_VAR_EXT.nextRow();
IT_VAR_EXT.setValue("OBJ_TYPE", "ECTC");
IT_VAR_EXT.setValue("OBJ_NAME", "Z_TK_METAKONF");
IT_VAR_EXT.setValue("VAR_EXT_MODE", "X");
IT_VAR_EXT.setValue("VAR_EXT_FILE", "MetaskriptVariantsFile.txt");
IT_VAR_EXT.setValue("VAR_EXT_PATH", "c:\\users\\rschuma\\SAPTest");
ecattExecute.getImportParameterList().setValue("IT_VAR_EXT", IT_VAR_EXT);

 

Der Aufbau des Variantenfiles hängt davon ab, wie die Parameter innerhalb des Metaskripts organisiert sind. Ich empfehle der Übersichtlichkeit halber zuerst alle eCATT Import Parameter für das Metaskript selbst zu definieren und danach eine Reihe generischer eCATT Import Parameter für das Testskript selbst. Man kann in den Startoptionen der Meta-Testkonfiguration im Tab Variants über die Menüzeile ein passend formatiertes Variantenfile generieren. Dieses wird als Template verwendet und vor der Ausführung des Metaskripts mit den jeweils passenden Daten gefüllt. Das könnte in unserem Beispiel so aussehen:

Ein eCATT Variantenfile für das Metaskript

Ein eCATT Variantenfile für das Metaskript

 

Das Metaskript selbst hat folgenden Aufbau:

  1. Starte die Transaktion SECATT.
  2. Trage in das Feld Testskript $I_TESTSKRIPT_NAME ein und wähle Ausführen (F8).
  3. Wähle der Reihe alle Tabs in den Startoptionen aus und konfiguriere die Ausführung des eCATT Testskripts.
  4. Insbesondere: wähle im Tab Allgemein den richtigen (einmalig erstellten) Systemdatencontainer und trage in das Feld Zielsystem $I_ZIELSYSTEM
  5. Insbesondere: trage im Tab Parameter in die Tabelle der Reihe nach $I_PARAMETER_1, 2, 3… ein, solange bis die ganze Tabelle abgearbeitet ist. (dies sind die eigentlichen Test-Parameter, z.B. der Wert des Gutscheins)
  6. Führe das Testskript aus (F8). Das Metaskript pausiert, bis das Testskript abgeschlossen ist.
  7. Expandiere alle Knoten des angezeigten Testprotokolls.
  8. Speichere das Testprotokoll auf der lokalen Festplatte in einem (zuvor vereinbarten) Verzeichnis ab.

Die eCATT Export Parameter befinden im abgespeicherten Protokoll des Testskripts im Abschnitt EXPORT <Testskriptname> und können leicht geparst werden. Falls das Testskript fehlgeschlagen ist, findet man die Fehlermeldung zwischen den Zeilen …RFC Zielsysteminfo Zielsystem… und IMPORT <Testskriptname>. War der Test erfolgreich, steht zwischen beiden Zeilen nichts.

 

Fazit

Jetzt klappt's: das Metaskript spielt "über Bande" und räumt alle Hindernisse aus dem Weg

Jetzt klappt’s: das Metaskript spielt „über Bande“ und räumt alle Hindernisse aus dem Weg

 

Setzen wir alle Puzzlestücke zusammen, so können wir in Java über JCo und eCATT in der SAP GUI Aktionen ausführen. Wir können Eingabeparameter setzen, Ausgabeparameter lesen und somit eCATT Skripte als Keywords in einem plattformübergreifenden Testframework nutzen. Der Verwaltungsaufwand liegt mit einer Datei für die Verbindung zum Solution Manager (Destinationfile), einer Datei für das Metaskript (Variantenfile) und je einem eCATT-Testprotokoll pro Ausführung im akzeptablen Bereich – alles andere passiert im Java Code oder in SAP.

Je nach konkretem Anwendungsfall lässt sich die Funktionalität auch als Client oder Generator kapseln. Für weitere Informationen hierzu empfehle ich den erklärenden Artikel Keywords, Clients, Generatoren – wovon reden wir überhaupt? von Markus Möslinger.

 

Ausblick

...und das war erst der Anfang

…und das war erst der Anfang

 

eCATT lässt sich auf einige ungewöhnliche Arten nutzen, wie man an der Funktion des Metaskripts sehen kann. Man kann eCATT neben der „gewöhnlichen“ Testautomatisierung auch zur Testdatensuche, Testdatenerstellung (hier geschehen) und für Vorbereitungsaufgaben zur Unterstützung des manuellen Tests einsetzen. All diese Möglichkeiten stehen jetzt auch über Java zur Verfügung.

Die Notwendigkeit von Skripten, die ja auch erstellt und gepflegt werden wollen, erhöht zwar die Komplexität für ein Testframework. Dafür kann man die eCATT-Skripte aber auch innerhalb der SAP-Welt weiterverwenden. In Ihrer Organisation läuft ein weiteres Projekt, das sich ausschließlich in SAP bewegt, dort aber auf gemeinsame Komponenten zugreift? Dann nutzen Sie die eCATT-Skripte doch auch dafür. Falls das Parallelprojekt SAP auch zum Testmanagement nutzen will, erhalten Sie im Artikel von Christoph Menke nützliche Informationen.

Neben eCATT können Sie auch weitere Funktionen von außen ansteuern. Als Beispiel sei das mit eCATT stark verwandte Tool CBTA erwähnt, das auf Web Dynpro und Web GUI Oberflächen ausgerichtet ist. Auch der direkte Aufruf von Transaktionen ist möglich, sofern passende RFCs vorhanden sind.

Neben dem beschrieben SAP Java Connector existiert auch noch der .NET Connector. Um diesen geht es hier zwar nicht, er bietet aber dieselben Möglichkeiten für Visual Basic .NET, C# und Managed C++ und eignet sich damit für Frameworks, die sich stärker in der Microsoft-Sphäre bewegen.

 

…nur Mut!

Die Verbindung der SAP/eCATT Testautomatisierung mit der „Außenwelt“ erfordert durchaus einigen initialen Aufwand – wenn Sie das hier lesen, haben Sie sich immerhin durch einen der technischsten Artikel dieses Blogs gebissen. Der Aufwand lohnt sich aber: eCATT lässt sich nahtlos in ein Testautomatisierungs-Framework einbinden und für vielfältige Aufgaben nutzen.

 

(The Incredible Machine: https://de.wikipedia.org/wiki/The_Incredible_Machine)

 

Passende Artikel

Kommentare gesperrt.