Teil 3: Testautomatisierung – Konzeption eines Frameworks

Im zweiten Teil der RFC Blogreihe Testautomatisierung ging es um die Aktivitäten in den einzelnen Projektphasen und den Möglichkeiten der Automatisierung.

In diesem Blog beschäftigen wir uns mit den logischen und technischen Aspekten, die bei der Konzeption eines Automatisierungsframeworks zu berücksichtigen sind.

Automatisierungsframework

der Konzeption eines Automatisierungsframeworks (siehe Abbildung 1) kann zwischen der technischen und der logischen Konzeption unterschieden werden.

Abbildung 1: Testautomatisierungsframework

Im Allgemeinen gibt es mehrere Schnittstellen, über die ein Testobjekt getestet werden kann und die damit bei der technischen Konzeption zu berücksichtigen sind:

1. Grafische Benutzerschnittstelle
2. Webapplikationen und -services
3. CSS-Selektoren
4. Datenbanken und weitere Datenhaltungssysteme

1. Die grafische Benutzerschnittstelle (GUI – Graphical User Interface) ist eine der meistverbreiteten Benutzerschnittstellen, da der klassische Systemtest zu meist über diese Schnittstelle erfolgt, diese Schnittstelle anschaulich und verständlich ist, das Systemverhalten im realen Umfeld am besten nachstellt und damit implizit das dahinter liegende System getestet wird. Ein wesentliches Problem beim Aufzeichnen von Mausbewegungen und Tastaturbenutzung ist, dass eine andere Bildschirmauflösung oder Fenstergröße oder kleine Änderungen an der Benutzeroberfläche die Aufzeichnungen wertlos machen können. Es ist daher vorzuziehen, eine technische Schnittstelle zu wählen, die direkt auf die grafischen Elemente zugreift. Dazu müssen die anzusteuernden Benutzerelemente eindeutig identifiziert werden. Für eine stabile Identifikation müssen mehrere Kriterien bzgl. der Eignung einer Elementeigenschaft erfüllt sein:
   
   • eindeutiger Wert der Eigenschaft zur Identifizierung,
   • Unabhängigkeit von Bildschirmauflösung und Fenstergröße der Anwendung,
   • Unabhängigkeit von der eingestellten Sprache der Oberfläche (bei mehrsprachigen Applikationen) und/oder
   • Stabilität gegenüber Überarbeitungen der grafischen Benutzeroberfläche.

2. Webapplikationen stellen streng genommen einen Spezialfall im GUI-Bereich dar, bei denen die Kernfunktionen i.d.R. serverseitig realisiert sind und als Schnittstelle HTML dient. Die Benutzeroberfläche wird durch den jeweiligen Browser erzeugt. Die HTML-Schnittstelle schafft für Werkzeuge sehr gute Voraussetzungen, um auf die Elemente durch eindeutige IDs zuzugreifen. Einige Werkzeuge verwenden auch XPath für den Umgang mit Daten und Strukturen in XML-Format. Ähnlich funktionieren Webservices, bei denen das XML-Format als Schnittstelle dient.

3. Auch CSS-Selektoren funktionieren ähnlich wie XPath, aber mit dem Unterschied, dass diese nicht auf XML-Dokumente, sondern nur auf HTML-Dokumente angewendet werden können.

4. Die meisten Automatisierungstools bieten eine Schnittstelle zu gängigen Datenbanken an, um die Datenhaltung von Anwendungen zu testen. Die Überprüfung der Datenhaltung über die DB-Schnittstelle anstatt über das GUI hat den wesentlichen Nachteil, dass Änderungen am Datenmodell meist auch Anpassungen in der Automatisierung erforderlich machen. Für den Test mit großen Datenmengen sollten – um Performance-Probleme zu vermeiden – dafür spezialisierte Werkzeuge eingesetzt werden. Viele Werkzeuge unterstützen auch die in den gängigen Tabellenkalkulationsprogrammen verwendeten Formate. Die Datenhaltung bzw. Testdaten sind ein zentrales Thema im Bereich Test und sollte deshalb im Automatisierungskonzept einen hohen Stellenwert haben.

Neben der technischen Konzeption ist bei der logischen Konzeption die formale Form bzgl. der Erfassung der Testschritte und -daten für die Umsetzung von automatisierten Testfällen ein wichtiger Aspekt. Dabei ist auf einen modularen Aufbau der Testfälle zu achten, um die Wartung später möglichst effizient zu gestalten. Die datengetriebenen Testfälle unterscheiden sich lediglich in ihren Testdaten (verschiedene Datenkonstellationen), aber nicht in ihrem prinzipiellen (fixen) Ablauf. Diverse Testmethoden lassen sich mit diesem Ansatz entsprechend gut umsetzen:

• Äquivalenzklassenbildung
• Grenzwertanalyse
• Klassifikationsbaummethode
• Ursache-Wirkungs-Beziehungen
• Entscheidungstabellen

Muss eine Vielzahl von unterschiedlichen Abläufen abgedeckt werden, so eignet sich hierfür die schlüsselwortgetriebene Testfalldarstellung. Zunächst ist zu definieren, aus welchen Schritten (Schlüsselwörtern) die umzusetzenden Testfälle bestehen. Die einzelnen Schritte werden dann automatisiert und dem Tester in Form eines Baukastensystems zur Verfügung gestellt. Ziel ist es, die Abläufe in Schritte aufzuteilen, die

• klein genug sind, um ein möglichst flexibles Testfalldesign zu ermöglichen (→ gut wartbar) und
• groß genug sind, um einen fachlichen Fokus zu besitzen (→ für den Tester leicht nachvollziehbar).

Dabei ist jedoch unbedingt darauf zu achten, dass durch die Übergabe von Parametern und die Bildung von Varianten der Schlüsselwörter nicht eine undurchschaubare und unwartbare Ansammlung von Testabläufen entsteht!

Die beschriebenen logischen Konzepte können zwar mit den meisten kommerziellen Werkzeugen umgesetzt werden, sind aber nicht robust gegenüber typischen Ereignissen im Lebenszyklus einer Applikation:

• • Technische Veränderungen der zu testenden Applikation:

Die Qualität der Konzeption beeinflusst stark die Robustheit gegenüber dieser Art von Veränderungen.

• • • Veränderungen am Automatisierungsframework, z.B. Wechsel des Automatisierungswerkzeugs:

  Auch hier beeinflusst die Qualität der Konzeption stark die Robustheit gegenüber dieser Art von Veränderungen – insbesondere, wenn herstellerspezifische Methoden verwendet werden.

• • Fachliche Veränderungen der zu testenden Applikation:

Die Überarbeitung der betroffenen Teile der Automatisierung – im schlimmsten Fall eine Anpassung aller Testfälle – ist erforderlich. Dies ist gerade dann ärgerlich, wenn die abzudeckende Kernfunktionalität nicht betroffen ist, sondern „nur“ Vor- und Nachbereitungsschritte von Testfällen.

Ziel der Testfallkonzeption muss es sein, langfristig den Wartungsaufwand möglichst gering zu halten, auch wenn damit kurzfristig ein höherer Initialaufwand verbunden ist. Dazu werden zunächst die Testschritte in die folgenden vier Kategorien eingeteilt:

1. Vorbedingungen / Initialisierung
2. Testschritt(e)
3. Prüfung(en)
4. Nachbedingungen / Bereinigung(en)

Dabei sollten die Vor- und Nachbedingungen möglichst nicht Bestandteil der fachlichen Testfälle sein, so dass diese kürzer, besser lesbar und wartbarer sind. Die Bereinigung kann beispielsweise durch das Testframework implizit nach der Durchführung eines Testfalls erledigt werden. Ein weiterer Vorteil dieser Auslagerung ist, dass diese Schritte ggf. nicht mehr über die gleiche Schnittstelle wie die eigentlichen Testschritte durchgeführt werden müssen (z.B. SOAP). Der initial höhere Aufwand rechnet sich insbesondere bei einer großen Anzahl von Testfällen oder auch sehr komplexen Testfällen.

Die folgenden Kriterien können bei der Entscheidungsfindung für die Testfalldarstellung helfen:

• Benutzer: rein fachliche Tester vs. Tester mit Entwicklungserfahrung
• Anzahl der Testfälle: Wahl einer leicht wartbaren Darstellungsform bei einer hohen Anzahl
• Ähnlichkeit zwischen Testfällen: Verwendung einer bestimmten Entwurfsmethode als Indikator
• Komplexität der Testfälle: viele einfache und wenige komplexe Testfälle (Lösung: Automatisierung der einfachen Testfälle und manuelle Durchführung der komplexen Testfälle)

Oft lassen sich die daten- und die schlüsselwortgetriebene Darstellungsform bei der Automatisierung von Testfällen auch kombinieren.

Es gibt einige wesentliche Faktoren, die sowohl bei der Verwendung von Werkzeugen als auch beim Design eines nachhaltigen Automatisierungsframeworks zu beachten sind. Zu Beginn müssen zunächst die Anforderungen an das Framework definiert werden:

• In welcher Darstellungsform erfolgt die Definition der zu automatisierenden Testfälle?
• Welche Systemschnittstellen werden verwendet?
• Auf welcher Art erfolgt die Testdurchführung und -protokollierung?

Dabei kann sich herausstellen, dass nicht ein einziges Werkzeug alle o.g. Anforderungen erfüllt. Werden die Testfälle direkt in Skripten bzw. Programmcode eines Werkzeugs erfasst und gespeichert, so besteht eine direkte Abhängigkeit zum Tool. Um möglichst unabhängig von Werkzeugen zu sein, empfiehlt sich eine mehrschichtige Struktur:

Abbildung 2: Mehrschichtiger Aufbau eines Automatisierungsframeworks

Die oberste (businessspezifische) Schicht wird durch Testdaten und Testabläufe gebildet, die die fachlichen Informationen enthalten und Basis für die auszuführenden Testfälle sind. Änderungen des Testobjekts bzgl. der Anforderungen wirken sich direkt auf die betroffenen Testfälle aus. Die abarbeitende Schicht interpretiert die formalisierten Testdaten und -abläufe und zerlegt diese in konkrete fachliche Schritte. Wichtiges Ergebnis beim Entwurf dieser Schicht ist, eine verständliche Spezifikation der Testabläufe zu erzielen. Änderungen des Testobjekts bzgl. der Anforderungen hat normalerweise keine Auswirkungen auf diese Schicht. Anpassungsbedarf auf dieser Ebene entsteht eher, um die Testeffizienz oder Testtiefe zu verbessern. Die technisch-fachliche Schicht transformiert die fachlichen Testschritte in technische Aktionen und führt diese über Schnittstellen oder mit Hilfe von Werkzeugen auf dem Testobjekt aus. Diese Ebene dient als Adapter und erlaubt, Werkzeuge und Schnittstellen (z.B. Datenbank, GUI, Webservice) zu kombinieren und bei Bedarf auszutauschen, ohne die abarbeitende Schicht und damit auch die Testfälle anpassen zu müssen. Ändert sich das Testobjekt technisch, so müssen i.d.R. nur auf dieser Ebene Anpassungen erfolgen.

Die Umsetzung eines Automatisierungsframeworks ist Entwicklungsarbeit und erfordert eine strukturierte Vorgehensweise und das Know-how von Spezialisten:

• Bottom-up: Start mit Schnittstellen zum Testobjekt
• Top-down: Start mit der Speicherung und Verarbeitung von Testabläufen und Testdaten

Eine Qualitätssicherung des entwickelten Automatisierungsframeworks ist zwingend erforderlich, um später Fehler im Framework möglichst ausschließen zu können. Wichtig ist aber auch, die Verantwortlichkeiten innerhalb der Organisation des Unternehmens klar zu definieren:

• • Automatisierungsframework (Kernsystem):

Das Kernteam besteht aus entwicklungsnahen Automatisierern und Technologie-Spezialisten

• • Testdaten:

Experten für die jeweilige Datenquelle

• • (externe) Applikationen und Schnittstellen:

Testautomatisierer sowie Experten der jeweiligen Anwendung

Fazit

Für die Umsetzung der Testautomatisierung sind oft keine dezidierten Ressourcen verfügbar, sondern sie erfolgt als Nebenprodukt durch das Testteam. Dieses hat allerdings oft nur eine sehr rudimentäre Erfahrung im Bereich Automatisierung. Testautomatisierung erfordert aber sehr spezifische Fähigkeiten: Der Aufbau und die Wartung eines Frameworks für die Automatisierung ist eine sehr komplexe Aufgabe und erfordert Kenntnisse über die bestehende Infrastruktur und den technischen Aufbau des zu testenden Systems.

Erfahrungsgemäß wird Testautomatisierung in vielen Projekten erst dann ein Thema, wenn der manuelle Test an die Ressourcengrenzen stößt. Der erste Lösungsansatz ist in vielen Fällen die Anschaffung eines Testwerkzeugs. Das ist aber i.d.R. nicht zielführend. Die Einführung eines Automatisierungsframeworks erfordert eine strukturierte Vorgehensweise. Für eine größtmögliche Unabhängigkeit empfiehlt sich eine mehrschichtige Struktur sowie die Festlegung von Verantwortlichkeiten. Bei der logischen und technischen Konzeption eines Automatisierungsframeworks ist es wichtig, darauf zu achten, robust gegenüber technischen und fachlichen Veränderungen im Lebenszyklus der zu testenden Applikation zu sein. Auch Anpassungen am Framework sollten möglichst nur geringe Auswirkungen haben. Ziel ist es, langfristig den Wartungsaufwand gering zu halten. Die automatisierte Abarbeitung von Testfallspezifikationen in natürlicher Sprache ist noch Vision und nicht realisiert.

Ausblick:

Im vierten Teil der RFC Blogreihe zum Thema Testautomatisierung geht es um die Integration in die Organisation eines Unternehmens.