eCATT & OpenSource - Automatisierter Test in heterogenen Systemlandschaften

26.11.2015, Christoph Menke
@christoph_hb
eCATT & OpenSource
Automatisierter Test in heterogenen Systemlandschaften

1
Heterogene Systemlandschaften und
Testautomatisierung

© 2015 ANECON | eCATT & OpenSource - Automatisierter Test in heterogenen Systemlandschaften 3
Heterogene Systemlandschaft
› In den meisten Unternehmen gibt es innerhalb der Systemlandschaft verschiedene
Technologien und Plattformen.
Systemlandschaft
SAP, Java, C#,
.NET…
Windows, Linux,
OS X… Web, Desktop,
Mobile…

One tool to rule them all…
› Diverse Toolhersteller bieten kommerzielle
Testautomatisierungswerkzeuge an, welche viele
Technologien bedienen können.
Foto Georg Mittenecker CC BY-SA 2.5
+ Eine Plattform für alle
Testautomatisierungs-
aktivitäten
+ Technologieübergreifen
de Tests out-of-the box
 Abhängigkeit von einem
Tool/Hersteller
 Hohe Lizenzgebühren
 Generalist

Mochi wa mochiya.
Was den Reiskuchen betrifft, kommt nur der Reiskuchenladen in Frage.
Japanisches Sprichwort
› Andere OpenSource Projekte und Hersteller spezialisieren
sich auf einen oder wenige Zwecke.
+ Bei OpenSource keine
Lizenzkosten
+ Gute Unterstützung des
Spezialgebiets
 Mehrere Werkzeuge bei
heterogener Landschaft
 Technologieübergreifen
de Tests aus einem
Werkzeug nicht möglich
 Spezialist Foto Christian Mehlführer CC BY-SA 2.5

Das Beste aus beiden Ansätzen nutzen
› Vorteile der Ansätze Generalist und Spezialist nutzen und die Nachteile durch
ein geeignetes Framework einschränken.
Foto Georg Mittenecker CC BY-SA 2.5
Foto Christian Mehlführer CC BY-SA 2.5
SAPWebDB
FrameworkTestfälle
(z.B. in FitNesse, HP
ALM, Solution Manager)
eCATTSeleniumSQL
Keywords
Daten-
generatoren
Clients

Keywords

Datengeneratoren
› Dynamische Testdatensuche
› Testdatenerstellung und Testdatenrücksetzung
› Einspielen von Datenbankabzügen
› Zugriff auf Testdatencontainer

Clients
› Anbindung von Testautomatisierungswerkzeugen
› Konkrete Ausprägung der Keywords (gekapselt)
› Möglichkeit zum Einbinden eines Clients hängt stark von dessen Schnittstellen
nach außen ab
› Bereits angebundene Testwerkzeuge
 Selenium (Web), SeleniumMobile (Mobile), Seetest(Mobile), IBM RFT
(Mobile, .NET, SAP, Adobe PDF, Siebel), eCATT (SAP), CBTA (SAP),
SoapClient (APIs)…

Tool vs. spezifische Situation
Testfälle sollen sein
› Stabil gegenüber irrelevanten Änderungen
› Fachlich nachvollziehbar
› Eigenständig durchführbar
› Wartbar
Tools sind generisch
Anwendungssituationen nicht
 Aufbau einer fachlichen Sprache

HP ALM
Framework
Keywords
Daten -
generatoren
Clients
MS TFS
Jenkins
Deployment
Source Code Verwaltung
Tests automatisieren
Testfälle ausführen
Reports erstellen
Tests beschreiben
SAP
Web
Mobile
…
Beispiel für eine Framework-Implementierung

Entwicklung eines eCATT Clients
eCATTSAP JCo
Framework
Keywords
Daten-
generatoren
Clients
ECATT_EXECUTE

Meta-
Testkonfiguration
Testfall
Funktionsweise eCATT Client
Keyword
Parameter
SAP
Keyword
Parameter
Keyword
Systemdatencontainer
Testdaten
Metaskript
Testskript
Variantenfile
Enthält Input Parameter
für Testskript + weitere
Parameter für Metaskript
Testskript-Protokoll
Enthält Export-Parameter
des Testskripts, Protokoll-
ID, Resultat (PASS/FAIL)
1 erzeugt
2 startet
via JCo
3 liest
4 füllt mit Daten
5 konfiguriert, übergibt
Input Parameter für genau
diese Ausführung, startet
6 speichert7 Liest & parst
Framework Festplatte SAP
obligatorisch
optional

Fazit zur Frameworklösung
+ Spezialistenwerkzeuge kümmern sich um
die Technologien, die sie am besten
beherrschen
+ Testfälle sind unabhängig vom Werkzeug
beschrieben
+ Der Einsatz von OpenSource Werkzeugen
ist möglich
+ Tests und Reporting über
Technologiegrenzen hinweg
+ Unabhängigkeit von Werkzeugherstellern
 Testskripte müssen in verschiedenen
Werkzeugen entwickelt werden
 Anfangsaufwand ist höher als bei einer all-
in-one Lösung

3
Exkurs: Tipps für Testautomatisierer

© 2015 ANECON | Selenium oder CBTA - Automatisierter Test von Weboberflächen im SAP Umfeld 17
I. Hör auf die Tester
• Tester haben einen Blick für Risiken
• Tester kennen ihren Testgegenstand meist gut
Hör auf sie – denn sie sagen genau, was nötig ist
• Biete ihnen Hilfestellungen an
• Hilf ihnen, im Testen besser zu sein
• oder …
• Du stehst mit einem Haufen Testfälle da,
• die alle letztendlich das Selbe testen
• Gute Testfälle sind essentiell
„If you automate a mess, you get an automated mess.“

II. Verwende das passende Werkzeug
Kein Werkzeug deckt alle Bedürfnisse ab
› Vertraue nicht blindlings einem Werkzeug alles an
Es gibt spezifische Aufgaben für Werkzeuge
› GUI
› Last
› Unit
› Datenbank
› Webservice
Das Werkzeug sollte zum Benutzer passen
Ein gutes Framework kann mehrere
Werkzeuge integrieren

III. Definiere Geschäftsprozesse
Halte technische Details aus Deinen Testfällen raus
Verwende eine klar definierte „Sprache“, um die Testfälle
formal zu beschreiben
Daten- und schlüsselwortgetriebene Ansätze sind übliche
Testautomatisierungstechniken

IV. Denke erst über dein Vorgehen nach
• Schreibe zunächst die Anforderungen
• Leite daraus eine technische Lösung ab
• Verschiedene Testtypen brauchen verschiedene
Vorgehensweisen
• Daten- bzw. schlüsselwortgetriebene Ansätze sind vielseitig
einsetzbar
• Können für verschiedenste Vorgehensweisen
verwendet werden
• Manchmal muss man aber auch über den
Tellerrand hinaus denken …
• Sei offen für verschiedenste Testarten

V. Bilde nicht die zu testende SW nach
Vermeide es wo möglich, die Funktionalität der zu testenden
Software nachzubilden.
Beispiele:
› Rechner, prüfe die Summenfunktion
› Schreibe deine Testfälle nicht so:
‒ A = 5, B = 3, Ergebnis: A + B
› Schreibe lieber so:
‒ A = 5, B = 3, Ergebnis: 8
Es ist leichter, die Testdaten als das Testskript anzupassen,
wenn sich die zu testende Software ändert.

VI. Definiere einen Ausgangszustand
Halte einen definierten Start- und Endpunkt für deine Testfälle
ein
› Räume auf (vor dem Test)
Habe die Testumgebung im Griff!
› Definierte Testdaten laden
› Mocking, Simulation, ...
Diese Dinge könnten den manuellen Test stören
› Überlege eine separate Automatisierungsumgebung

VII. Respektiere den Detailgrad!
• Testfälle zielen auf spezifische Dinge ab!
• Zu wissen, was schiefgegangen ist, ist wichtig
 Halte Testfälle voneinander unabhängig
• Testfälle werden fehlschlagen  Abhängigkeiten sind böse!
• Im Idealfall kann jeder Testfall alleine ausgeführt werden
• Lange Ketten in eigene Testfälle geben

VIII. Sei ein Vollzeit-Automatisierer!
• Es ist viel zu lernen…
• Umgebung
• Fachlichkeit des SUT
• Technische Aspekte des SUT
• Tools
Dieses Wissen könnte vielen nutzen…
• Stelle Sicher, dass DEINE Ziele erreicht werden
• Zumindest ein Vollzeit-Tester sollte (zusätzlich) im Team sein
• Lerne „Nein“ zu sagen

IX. Verfolge Nutzen und Ziele!
• Automatisierung muss Nutzen stiften
• Verfolge, wie oft Testfälle laufen, welche Regressionen sie
finden
• Informationen über Testfall-Fehlschläge
• SUT
• Environment
• Tool
• Framework
• Testfälle
• Testdaten
• Interpretiere die Daten und gehe Schwachpunkte aktiv an!

X. Zeige deinen Fortschritt!
• Zeige
•Nutzen!
•Neue Testfälle / getestete
Funktionalität
•Abdeckung
•Verbesserungen
•Blockaden & Herausforderungen
•Testläufe & Ergebnisse
• Frage nach Feedback und Ideen

XI. Don‘t Panic!

ANECON. Weil A vor B kommt.
ANECON Software Design und Beratung GmbH
Bautzner Str. 147a, 01099 Dresden | www.anecon.com
office@anecon.com | Tel.: +49 351 207 497 20
christoph.menke@anecon.com @christoph_hb
Christoph Menke

eCATT & OpenSource - Automatisierter Test in heterogenen Systemlandschaften

Recommended

Recommended

More Related Content

What's hot

What's hot (14)

Similar to eCATT & OpenSource - Automatisierter Test in heterogenen Systemlandschaften

Similar to eCATT & OpenSource - Automatisierter Test in heterogenen Systemlandschaften (20)

eCATT & OpenSource - Automatisierter Test in heterogenen Systemlandschaften