Teil 2: Testautomation Der Testprozess – Aspekte der Automatisierung

Bei der Protokollierung der automatisierten Testdurchführung ist zu berücksichtigen, dass bei der Wiederholung von Testläufen die vorherigen Ergebnisse nicht überschrieben werden. Außerdem muss die Protokollierung so granular sein, dass aufgetretene Fehler lokalisierbar und nachvollziehbar sind. Im Rahmen der Bewertung werden die Testergebnisse gegen die Testendekriterien geprüft. Häufig wird die Anzahl der offenen Fehler pro Fehlerklasse als Testendekriterium verwendet. Fatale und einsatzverhindernde Fehler müssen auf jeden Fall behoben sein, für schwere und „störende“ Fehler gibt es gewisse Toleranzen, die akzeptabel sind. Denkbar ist auch die Kombination von Testendekriterien, z.B. Fehleranzahl und Testabdeckung von Anforderungen.

Zum Projektabschluss sollte im Nachgang die Testautomatisierung kritisch analysiert werden:

• Wurden die gesteckten Ziele erreicht?
• Hat sich die Investition in automatisierte Tests gegenüber manuellen Tests gelohnt?
• Gab es unvorhergesehene Probleme, z.B. bei der Umsetzung von Testfällen oder dem Testframework?
• Wie sieht es mit der Wiederverwendbarkeit aus?
• Gab es Ressourcenprobleme bzgl. der geforderten Skills?
• Gab es große Abweichungen zwischen den geschätzten und den tatsächlichen Aufwänden?

Einfluss auf die Relevanz der Testautomatisierung hat auch das Projektvorgehen:

• Klassisches Vorgehensmodell nach dem Wasserfallprinzip
  

  Die Testautomatisierung darf nicht auf den wiederholten Regressionstest reduziert werden, da gerade in Projekten mit langen Zyklen andere Argumente für eine Automatisierung sprechen:

  • Höhere Testtiefe
  • Breitere Testabdeckung
  • Manuell schwer zu testende Testobjekte, z.B. Schnittstellen

• Agiles Vorgehensmodell mit iterativem Vorgehen
  

  Hier muss zu jedem Iterationsende ein Testergebnis vorliegen, d.h. es müssen die neuen und geänderten Funktionalitäten getestet werden. Zusätzlich ist meist noch ein Regressionstest des bereits bestehenden Systems notwendig Dies ist manuell nicht zu leisten und erhöht die Notwendigkeit einer Testautomatisierung bei agilem Vorgehen massiv. Ein automatisierter Regressionstest ist daher in vielen Fällen zwingend, da bereits nach wenigen Iterationen die Funktionalität des Systems zu umfangreich für einen manuellen Regressionstest mit ausreichender Abdeckung sein wird.

Testfallspezifikation

Bereits das Design von Testfällen sollte möglichst automatisiert erfolgen, da die erstellten Testfälle im Vergleich zu manuell erstellten Testfällen im Fließtext leichter automatisiert bearbeitet werden können.  Die folgenden Entwurfsmethoden können bei der Abdeckung von Kombinationen helfen, da die Menge an erstellten Testfällen später optimal mit einer datengetriebenen Automatisierung (Kombinatorik) abgearbeitet werden können:

• Äquivalenzklassenbildung
  

  Aufteilung eines Wertebereiches in Klassen mit gleichartigem Verhalten

• Grenzwertanalyse
  

  Beruht auf der Annahme, dass an den Grenzen von Definitionsbereichen mehr Fehler auftreten als innerhalb des Gültigkeitsbereichs

• Klassifikationsbaummethode
  

  Aufteilung der zu testenden Elemente in Klassen und Ableitung von Kombinationsmöglichkeiten und Ableitung konkreter Testfälle aus der Gesamtmenge nach den folgenden Kriterien:

• • Minimal: jeder gültige Repräsentant mindestens einmal im Testfallset vorhanden
  • Paare: jede mögliche Paarung aller gültigen Repräsentanten im Testfallset vorhanden
  • Tripel: jede mögliche Konstellation von 3 gültigen Repräsentanten im Testfallset
  • Maximal: jede mögliche Kombination aller gültigen Repräsentanten im Testfallset

Es gibt zwei Ansätze, um die generierten Testfalldatensätze bei der Testdurchführung zu verwenden:

• Generierung von konkreten Testfallabläufen aus den Testdaten:
  

  Erzeugung konkreter Testfallabläufe auf Basis der Datensätze

• Auslesen der Testdaten während des Testfallablaufs:
  

  Iterative Testdatenverarbeitung zur Laufzeit mit dem Vorteil: Datenanpassungen erfordert keine Ablaufanpassung, aber Änderungen für Einzelfälle (spezielle Regeln) erfordern einen eigenen Ablauf

Auch auf Basis von Modellen können systematisch Testfälle abgeleitet werden. Bei einem Zustandsmodell zum Beispiel können aus den Zustands- und Übergangsbeschreibungen die erforderlichen, zu automatisierenden Testfälle abgeleitet bzw. generiert werden. Dabei erhöht die direkte Verbindung der Testfälle zur Spezifikation die Stabilität und Wartbarkeit der automatisierten Testfälle. Die notwendige Testtiefe wird über das Überdeckungsmaß gesteuert, zum Beispiel:

• Zustandsüberdeckung: jeder Zustand ist mindestens einmal im Testfallset vorhanden
• Übergangsüberdeckung: jeder Übergang zwischen zwei Zuständen ist im Testfallset vorhanden
• Pfadüberdeckung: jeder mögliche Pfad ist im Testfallset vorhanden

Der modellbasierte Ansatz bietet gegenüber einer klassischen Testfallbeschreibung in Textformat viele Vorteile:

• Modularer Aufbau ermöglicht verschiedene Abstraktionsebenen.
• Systematische Ableitung der Testfälle nach vorgegebenen Regeln.
• Automatisierbare Generierung der Testfälle aufgrund der formalen Darstellung möglich.
• Wiederverwendbarkeit und Toolunterstützung erhöht Wartbarkeit und vermeidet Redundanzen.
• Sukzessive Integration möglich, z.B. zunächst nur Priorisierung, später automatisierte Generierung.
• Verständliches Modell verschafft einen guten Überblick und eine gute Kommunikationsgrundlage.

Die automatische Generierung von Testdaten erfordert im Allgemeinen eine formale Beschreibung der zu erstellenden Datensätze. Diese kann in unterschiedlichen Formen erfolgen, z.B.:

• Pseudodatensätze in (E)BNF (Erweiterte Backus-Naur-Form)
• XML als Standard für die Erfassung von maschinenlesbarer Dokumentation

Testdurchführung

Automatisierte Tests sind i.d.R. wiederholbar und als eine Art von Regressionstest angelegt. Dabei kann bzgl. der zeitlichen Taktung bei der Testdurchführung zwischen den folgenden Arten unterschieden werden:

• Ständige Durchführung
  

  Meist im Rahmen der inkrementellen (agilen) Entwicklung, z.B. bei Continuous Build bei Codefreigabe zwingend erforderlich. Primäres Ziel ist nicht neue Funktionalität zu testen, sondern ein Regressionstest, der sicherstellt, dass die Änderungen bereits korrekt funktionierende Programmteile nicht beeinflussen.

• Häufige Durchführung
  

  Tests, deren Durchführung nach jeder Änderung am zu testenden System zu lange dauern würden, können alternativ in relativ kurzen (z.B. mehrtägigen) Abständen durchgeführt werden. Primäres Ziel ist auch bei dieser Taktung weniger der Test neuer Funktionen, sondern der Regressionstest, da es zeitlich meist nicht möglich ist, alle (neuen) Systemtestfälle vollständig zu automatisieren.

• Fallweise Durchführung
  

  Meist im Rahmen der sequenziellen Entwicklung, z.B. eine Testdurchführung ist bei nicht automatisierten Deployments aus Aufwands- bzw. Zeitgründen nicht in kurzen Abständen möglich.

Bei Fehlschlagen eines automatisierten Tests sind viele Fehlerquellen in Betracht zu ziehen (siehe Abbildung 3):

• Fehler im Automatisierungswerkzeug: Auch Tools sind nicht fehlerfrei.
• Fehler im Automatisierungsframework: Oft müssen Testwerkzeuge um Funktionalitäten (z.B. für die Integration weiterer Schnittstellen) erweitert werden. Wichtig ist, Fehler im Framework nicht irrtümlich dem zu testenden System zuzuordnen.
• Fehler im automatisierten Testfall(-ablauf): Wichtig ist, neu erstellte automatisierte Testfälle ausführlich zu testen (ggf. Debugging) bevor sie in das Automatisierungstestset aufgenommen werden.
• Fehlerhafte Testdaten: Oft führen nicht geeignete Testdaten zu Fehlern bei der Testdurchführung.
• Fehlerhaft verwendete Fremdsysteme: Die Integration von Fremdsystemen in die Automatisierung kann ebenfalls Quelle für das Fehlschlagen eines Testfalls sein.
• Änderungen am Testobjekt: Werden Anpassungen am Testobjekt nicht berücksichtigt, so kann auch dies eine mögliche Fehlerquelle bei der Testdurchführung sein.
• Fehler im zu testenden System: Ziel der Automatisierung ist, diese Art von Fehler

Anhand der Vielzahl von möglichen Ursachen ist es enorm wichtig, die Fehlerursache für einen fehlgeschlagenen Testfall genau zu untersuchen. Hierfür sollten ausreichende Informationen bei der Testdurchführung protokolliert werden, um die Fehlerursache(n) nachvollziehen und analysieren zu können.

Da das zu testende System nur eine von vielen möglichen Fehlerursachen darstellt, kann das automatisierte Erfassen eines Fehlers im Fehlerverwaltungssystem viele Fehlermeldungen erzeugen, bei denen die Fehlerquelle nicht das Testobjekt ist. Wenn sich dennoch für eine automatisierte Fehlergenerierung entschieden wird, dann empfiehlt sich eine entsprechende Markierung des Fehlers zu Auswertungszwecken. Das Verhältnis von den im zu testenden System gefundenen Fehlern zu der Gesamtanzahl der fehlgeschlagenen automatisierten Testfälle gibt Aufschluss über die Effektivität und Stabilität der Testautomatisierung. Hilfreich bei der Fehlerauswertung kann ein eigenes Feld für die Fehlerursache sein.

Fazit

Bevor mit den Testaktivitäten in den einzelnen Prozessschritten begonnen wird, ist zu analysieren, wo eine Automatisierung sinnvoll ist, sowie eine Aufwandschätzung zu erstellen. Dabei sollte schon die Testfallerstellung möglichst automatisiert erfolgen und die Traceability über alle Prozessschritte hinweg gewährleistet sein. Bei der Testdurchführung ist die zeitliche Taktung ein wichtiger Aspekt, der zu berücksichtigen ist. Außerdem sind bei der automatisierten Testdurchführung eine Vielzahl von möglichen Fehlerquellen bei der Analyse von fehlgeschlagenen Testfällen einzubeziehen. Die agile Vorgehensweise setzt dabei ein hohes Maß an Integration und Interoperabilität der eingesetzten Werkzeuge voraus. Das Zusammenspiel zwischen Testprozessaktivitäten und der eingesetzten Werkzeuge ist generell ein zentrales Thema des Application Lifecycle Management.

Ausblick:

Im dritten Teil der RFC Blogreihe zum Thema Testautomatisierung werden wir uns mit der Konzeption eines Automatisierungsframeworks beschäftigen.