eCATT & OpenSource - Automatisierter Test in heterogenen Systemlandschaften

26.11.2015, Christoph Menke

@christoph_hb

eCATT & OpenSourceAutomatisierter 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

http://kamelopedia.mormo.org/index.php/Datei:Wollmilchsau.jpg

http://creativecommons.org/licenses/by-sa/2.5


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

https://de.wikipedia.org/wiki/Dreifinger-Faultiere#/media/File:MC_Drei-Finger-Faultier.jpg



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



SA

PW

eb

DB

FrameworkTestfälle(z.B. in FitNesse, HP

ALM, Solution Manager)

eC

AT

TS

ele

niu

mS

QL

Keywords

Daten-

generatoren

Clients

http://kamelopedia.mormo.org/index.php/Datei:Wollmilchsau.jpg









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

2

Die Frameworklösung


HP ALM

Framework

Keywords

Daten -

generatoren

Clients

MS TFS

JenkinsDeployment

Source Code Verwaltung

Tests automatisieren

Testfälle ausführen

Reports erstellen

Tests beschreiben

SAP

WebMobile

…

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 startetvia 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

[email protected] | Tel.: +49 351 207 497 20

[email protected] @christoph_hb

Christoph Menke