Tutorial: Testautomatisierung auf verschiedenen Stufen – 1. Überblick

Tutorial-Ziel:

In dieser Serie werden anhand eines sehr einfachen Beispiels die Testautomatisierungsansätze auf verschiedenen etablierten Stufen gemäß der Testautomatisierungspyramide erläutert.

Dabei werden die Methodiken der Testautomatisierung auf folgenden Stufen vorgestellt

• Unit Tests (White-Box)
• Integration Tests (White-Box)
• Integration Tests / Api Tests (Black-Box)
• System Tests / End-to-End Tests (Black-Box)

und anhand eines identischen Beispiel-Testszenarios gegenübergestellt, um die Unterschiede hinsichtlich

• des Automatisierungsaufwandes
• des erforderlichen Skills
• der erforderlichen Tools und Infrastruktur
• der typischen Testlaufzeiten und der Feedback-Loop Dauer  (die insbesondre im agilen Umfeld von zentraler Bedeutung ist)

zu verdeutlichen.

1. Überblick: Testautomatisierungs-Pyramide und verschiedene Stufen der Testautomatisierung

Bevor man sich mit den konkreten Techniken der Testautomatisierung beschäftigt, ist es wichtig zu verstehen, dass Testautomatisierung ein sehr breites Feld ist, das durch mehrere Dimensionen kategorisiert werden kann.

Dimensionen der Testautomatisierung:

• Stufe (Level):

  • Unit Tests
  • Integration Tests (white-box)
  • Integration Tests (black-box)
  • End-to-End Tests
  • Last & Performance Tests, Security Tests

• Schicht:

  • UI
    • Tests auf der UI Schicht interagieren mit der Benutzeroberfläche einer Applikation und simulieren damit die Aktivitäten des End-Benutzers
  • API / Middlerware
    • Tests auf der API bzw. Middlerware Schicht interagieren mit den öffentlichen Schnittstellen von Web- und Applikation-Servern und simulieren oft interne Geschäftsabläufe
  • Datenbank / Storage
    • Tests auf der Datenbank bzw. Storage Schicht greifen direkt auf die Datenhaltungsschicht zu, um komplexe Datentransformations- und ETL Prozesse möglichst ungefiltert und direkt zu testen

• Methode:

  • White-Box Tests:
    • diese Tests entstehen durch den Einblick in die Implementierung der zu testenden Applikation und werden deshalb auch als „Glass-Box“ Tests bezeichnet. Das setzt voraus, dass die Testentwickler einen direkten Zugriff auf den Code haben und diesen analysieren können. Dadurch könen die Tests interne Code-Flüsse und Strukturen optimal abdecken und interne Zustände und tlw. nicht-öffentliche Elemente überprüfen, ohne die Applikation bauen und bereitstellen zu müssen
  • Black-Box Tests:
    • diese Tests greifen auf die gebaute und bereitgestellte  Applikation (bzw. Bibliothek oder Service)  zu, indem sie mit den öffentlichen Schnittstellen der Applikation interagieren und das korrekte fachliche Verhalten (ohne Einblick in den Code) verifizieren.

• Fokus:

  • Funktional:
    • der Fokus der funktionalen Tests liegt darauf das korrekte fachliche Verhalten eines Produktes zu verifizieren
  • Nicht-Funktional (Last & Performance Tests, Security Tests, Usability Tests ….):
    • der Fokus der nicht-funktionalen Tests liegt darauf sicherzustellen, dass weitere betriebs- und nutzungsspezifische Aspekte wie Stabilität, Geschwindigkeit, Effizienz, Sicherheit und Benutzerfreundlichkeit in Hinblick auf die gestellten Anforderungen bzw. Akzeptanzkriterien erfüllt sind

Im Berufsalltag werden häufig die Test-Stufen und Test-Schichten fälschlicherweise vermischt. So werden z.B. die „End-to-End“ und „UI“ Tests oft als Synonyme behandelt. Das liegt daran, dass in der Praxis diese Ausprägungen besonders häufig in Kombination vorkommen. Dennoch gibt es auch etliche komplexe Unternehmensplatformen ohne Oberflächen (z.B. im Umfeld von ETL / Hadoop Systemen), für die man die Tests auf der „End-to-End Teststufe“ über die „API Schicht“ umsetzt. Genauso kann man bei der Nutzung moderner Unit Test und Mocking Frameworks auch die UIs auf der Stufe der Unit Tests durchtesten.

Testautomatisierungs-Pyramide

Im Kontext der Testautomatisierung (insbesondere im agilen Umfeld) hat sich der Begriff der Testautomatisierungs-Pyramide etabliert, die im wesentlichen die wichtigsten Test-Stufen abbildet, wobei die Form der Pyramide gleichzeitig die Schwerpunkte für die Testautoamtisierung im konkreten Projekt festlegt (als Teil der Testautomatisierungs-Strategie).

Folgende Formen dieser Pyramide sind in der Praxis häufig anzutreffen:

In der agilen Software-Entwicklung wird besonderer Augenmerk auf die „wohlgeformte“ Pyramide (linkes Bild) mit stark ausgeprägten Unit und Integrationstests und darauf abgestimmten reduzierten End-To-End Systemtests  gelegt. Auf diese Weise werden schnelle Feedback-Schleifen mit kurzen Testlaufzeiten und hoher Robustheit begünstigt.

Wie solche automatisierten Tests auf verschiedenen Teststufen umgesetzt werden können und warum die agile Test-Pyramide für die effektive Qualitätssicherung sehr wichtig ist, wird in den nächsten Kapiteln der Serie an folgendem anschaulichen Beispiel-Szenario demonstriert.

2. Beispiel-Szenario des Tutorials

Feature / User Story:

Das Beispiel Szenario in diesem Tutorial  basiert auf einer minimalistischen Kundenanforderung
eine einfache Applikation bereitzustellen, die lediglich die Multiplikation zweier ganzer Zahlen ermöglicht.

Die Applikation wird im folgenden als „Multiplikator“ bezeichnet.

Bevor man mit der Testautomatisierung beginnt, leitet man im nächsten Schritt zuerst die Testszenarien und die konkreten Testfälle basierend auf der obigen Beschreibung des Features ab. In agilen Projekten, vor allem bei der Anwendung von Test Driven Development, geschieht das in der Regel während der sogenannten 3-Amigo Session, an der jeweils ein Tester, ein Entwickler und ein Business Analyst teilnehmen. Dabei werden sowohl das Testszenario als auch die daraus abgeleiteten konkreten Testfälle häufig in einer semi-formalen Gherkin Notation formuliert ( als zentraler Bestandteil von dem Behavior Driven Development Ansatz).

Test Scenario

Für unser Beispiel verwenden wir folgendes allgemein formuliertes Test Szenario:

Scenario: „Sunny Day Case“

Angenommen der Benutzer hat die Applikation Multiplikator gestartet
Wenn er einen gültigen Operand_1 und Operand_2 eingibt und Multiplikation durchführt
Dann soll die Applikation das Produkt der eingegebenen Operanden als Ergebnis zurückgeben

Testfälle:

Für unser Test Scenario lassen sich folgende 3 konkrete Testfälle ableiten, die recht gut die fachliche Korrektheit der zu testenden Funktionalität verifizieren und damit die wichtigsten „Sunny Day“ Pfade abdecken:

 

Tesfall                        Operand_1    Operand_2    Ergebnis
1. Mult. positiver Zahlen          2            3            6
2. Mult. negativer Zahlen          2           -3           -6
3. Mult. mit Null                  0            3            0

Nachdem wir in diesem Teil die die grundlegenden Testautomatisierungsstufen kennengelernt haben und das Testszenario für dieses Tutorial vorbereitet haben, können wir in den nächsten Kapiteln die konkreten Implementierungen von Testautomatisierung auf verschiedenen Teststufen uns ansehen und gegenüberstellen.

Weiter geht es mit Unit Tests in Teil 2:

Testautomatisierung auf verschiedenen Stufen – 2. Unit Tests

Serienteile:

•  1. Teil – Überblick
• 2. Teil – Unit Tests
• 3. Teil – Integration und API Tests
• 4. Teil – End-to-End Tests (erscheint demnächst …)

Alexander Heimlich

Redakteur auf Testautomtisierung.org
Geschäftsführer, Schulungsleiter bei SimplyTest GmbH, Nürnberg
www.simplytest.de
Passionierter Softwareentwickler und Testautomatisierungsverfechter mit langjähriger beruflicher Erfahrung als Softwareentwickler, Test Automation Manager, Teamleiter und Projektleiter