Dieser Artikel erklärt, was ein Testautomatisierungs-Framework ist, und gibt Beispiele, die Sie für Ihre eigenen Entwicklungsprojekte berücksichtigen sollten. Dieser Blog von Alexandar Pushkarev auf EuroSTARHuddle.com, unserer Online-Community für kostenlose Software-Testressourcen.
Was ist ein Rahmen?
Laut Wikipedia ist ein Framework eine Abstraktion, in der Software, die generische Funktionalität bereitstellt, selektiv durch zusätzlichen benutzergeschriebenen Code geändert werden kann, wodurch anwendungsspezifische Software bereitgestellt wird [1]. Es ist nicht die am einfachsten zu verdauende Definition, und man kann normalerweise Schwierigkeiten haben, den Unterschied zwischen einem Framework und einer Bibliothek zu erkennen. Der Hauptunterschied zwischen Framework und Bibliothek besteht jedoch darin, wer was aufruft. Lange Rede kurzer Sinn, wenn Sie die Bibliothek verwenden, rufen Sie den Code der Bibliothek auf. Wenn Sie dagegen ein Framework verwenden, ruft es Ihren Code auf.
Test automation frameworks are by no means different. In general, a test automation framework is something that allows you to implement application-specific test automation solutions by writing and injecting some additional code. Surprisingly, in the test automation community, by framework, people often mean any test automation solution that happened to have any decent structure and design. Wikipedia also supports this opinion [2].
Der häufigste „Architekturtyp“ einer Testautomatisierungslösung, den ich gesehen habe, war etwas, das man als „großen Schlammball“ bezeichnen könnte. Und in einigen Fällen funktioniert es einfach großartig – solche Dinge brauchen nicht ewig zu implementieren, und es ist ziemlich einfach, für einige kurze Zeiträume zu unterstützen, wenn Sie eine begrenzte Anzahl von Tests haben.
Die wirklich herausfordernde Frage ist, warum und wann Sie ein echtes Testautomatisierungs-Framework benötigen und wann Sie sich für die einfachen „Big Ball of Dreck“-Testlösungen entscheiden können.
Beginnen Sie mit der Frage: “Warum?”
Alles in allem sind Test-Frameworks darauf ausgelegt, folgende Probleme zu lösen:
1. Komplexität testen
Je einfacher der Test auf der obersten Ebene ist, desto einfacher ist er zu erstellen, zu verstehen, zu kommunizieren und zu warten.
2. Wartungskosten testen
Testautomatisierung ist keine Selbstverständlichkeit; es hat einen Preis. Einer der schmerzhaftesten Preise für die Testautomatisierung sind die Wartungskosten. Ein gut gestaltetes Framework sollte die Wartung vereinfachen.
3. Testausführungszeit
Zeit ist Geld. Die Zeit, um Feedback von automatisierten Tests zu erhalten, ist ebenfalls entscheidend – man möchte nicht mehrere Stunden warten, nur um zu überprüfen, ob sein Commit nicht falsch war.
4. Berichterstattung
Beim Testen geht es darum, keine Fehler zu finden oder Geschichten zu akzeptieren. Nun, nicht genau. Beim Testen geht es wirklich darum, Informationen bereitzustellen. Eine Testlösung mit einfachen, wartbaren Tests – leicht zu warten und zu verbessern – wird möglicherweise einfach verworfen, wenn sie schlechte Berichte produziert, die für nicht-technische Beteiligte schwer verständlich sind.
Alles in allem, wenn Sie nicht vorhaben, Hunderte von komplexen Testszenarien zu haben, Ihre Tests schnell sind und Sie mit dem integrierten Xunit-Framework zufrieden sind, benötigen Sie möglicherweise überhaupt kein Testautomatisierungs-Framework. Als Faustregel gilt: Je niedriger die Teststufe, für die Sie sich interessieren, desto weniger komplex sollte Ihre Testautomatisierungslösung sein. In den meisten Fällen benötigen Sie kein Framework für Unit- oder Integrationstests, aber vielleicht möchten Sie eines für Akzeptanztests.
Unabhängig davon, an welcher Testebene Sie interessiert sind, gibt es einige typische Framework-Architekturen, die verwendet werden können. Interessanterweise wird die Framework-Architektur nicht durch den angewendeten Testautomatisierungsansatz (schlüsselwortgesteuert, BDD, einfacher Code oder was auch immer) beeinflusst, da diese Ansätze nur einige Schichten (vor allem Testschichten) betreffen und andere nicht berühren. Werfen wir dann einen Blick auf die bekanntesten Testframework-Architekturen.
Geschichtete Architektur
Während Testautomatisierungs-Frameworks entwickelt wurden, um die oben beschriebenen Probleme zu lösen, handelt es sich normalerweise nicht um ein übermäßig komplexes Softwaresystem. Das bekannteste Architekturmuster, bekannt als Layered Architecture, wird oft als Grundlage für die Framework-Architektur der Testautomatisierung verwendet.
Komponenten innerhalb der mehrschichtigen Architektur sind in horizontalen Schichten organisiert, und jede Schicht der Architektur hat eine bestimmte Rolle und Verantwortung in der Anwendung. Komponenten innerhalb einer bestimmten Schicht sollen sich nur mit Logik befassen, die dieser Schicht entspricht [3].
Dreischichtiges Automatisierungsframework
Die bekannteste und am weitesten verbreitete Architektur für Softwaretestautomatisierungslösungen ist eine dreischichtige Architektur; in dem die Lösung in drei logische horizontale Schichten unterteilt ist – normalerweise Testschicht, Geschäftsschicht und Kernschicht.
In einer solchen Architektur enthält eine Testschicht normalerweise selbst Testszenarien, entweder in Programmiersprache oder in irgendeiner anderen Form (wie BDD-Funktionsdateien).
Die Business-Schicht bietet spezifische Aktionen für das zu testende System (SuT). Wenn wir beispielsweise über Online-Shopping sprechen, können solche Aktionen „Anmelden“, „In den Warenkorb legen“ usw. sein.
In der Kernschicht lebt das echte Framework (das Ihren Code aufruft) wirklich, und es befasst sich mit der Testorchestrierung, Berichterstellung und bietet normalerweise auch eine Low-Level-API zur Kommunikation mit getesteten Anwendungen, wie Webdienstfassaden, Selenium-Webtreiber-Wrappern usw.
In einem BDD-inspirierten Framework enthält eine Testschicht typischerweise Funktionsdateien, eine Geschäftsschicht enthält Schrittdefinitionen, während eine Kernschicht die BDD-Framework-Konfiguration und Kernkomponente enthält. Bei einem datengesteuerten Framework enthält eine Testschicht Datendateien und eine Geschäftsschicht anwendungsspezifische Abstraktionen auf mittlerer Ebene.
Vier-fünf-Schichten-Automatisierungsframework
Falls Sie etwas Komplexeres benötigen, gibt es mehrere Optionen zur Verbesserung der Framework-Architektur. Eine der Optionen, die Sie wählen können, besteht darin, den Validierungscode in eine separate Ebene (oder genauer gesagt in ein Modul) zu extrahieren, die von einer Geschäftsschicht verwendet wird, während eine Kernschicht eine Schnittstelle oder Orchestrierung für die Validierung bereitstellen kann.
Falls Sie ein hybrides Framework erstellen, benötigen Sie möglicherweise eine separate Ebene für Daten, sodass Ihre Testebene Daten- und Nicht-Datentests enthält. All dies erhöht die Komplexität einer Kernschicht, daher kann es auch logisch sein, sie irgendwann in mehrere Unterebenen zu unterteilen.
Plug-fähiges Testautomatisierungs-Framework
Falls Ihre Anwendung noch komplexer ist, möchten Sie möglicherweise unterschiedliche Validierungen für unterschiedliche Umgebungen oder unterschiedliche Kommunikationswege mit Anwendungen für dieselben Tests (z. B. zum Testen von Desktop- und mobilen Versionen der Webseite). Es ist zwar möglich, dies durch die Erstellung von Untermodulen in Kern- oder Validierungsschichten anzugehen, aber es gibt auch eine nette Möglichkeit, dies für den Rest des Systems völlig undurchsichtig zu machen. Die Idee besteht darin, die Abhängigkeitsinjektion zu verwenden und steckbare Module für die Validierung und die Schnittstelle zwischen Testanwendungen bereitzustellen.
Die Idee ist im Wesentlichen die gleiche wie in früheren Framework-Architekturen, mit nur einem Unterschied – Validierung und Fassaden implementieren die bereitgestellte Schnittstelle, die von einer Geschäftsschicht verwendet wird, und die konkrete Implementierung wird normalerweise injiziert, ohne dass die anderen Schichten wissen, was wirklich injiziert wurde .
Überlegungen
While it is often tempting to pick up the most complex architecture (just in case) or the simplest thing (faster to implement), it is often wise to complete some initial investigation of what you need, based on product vision or expected length of life.
Vorausgesetzt, Architekturen sind keineswegs ein Standard, sie sind nur Beispiele, und Sie können ein steckbares dreischichtiges Ding implementieren oder sogar 7 verschiedene hierarchische Schichten identifizieren. Möglicherweise möchten Sie eine ereignisgesteuerte Sache zum Testen des asynchronen Workflows.
Es gibt mehrere typische Highlights:
1) Versuchen Sie, Tests so einfach, kurz und atomar wie möglich zu gestalten. Idealerweise sollten Tests sagen, was getan wird, nicht wie es getan wird, und nur eine bestimmte Sache testen. Typischerweise überwiegen die Kosten einer komplexen Testunterstützung die Vorteile solcher Tests.
2) Die Geschäftsschicht sollte eine Aktionsimplementierung bereitstellen (wie etwas getan wird), indem Schnittstellen verwendet werden, die von der Kernschicht bereitgestellt werden.
3) Die Validierungsschicht sollte eine Aktionsimplementierung unter Verwendung von Schnittstellen bereitstellen, die entweder von Kern- oder Geschäftsschichten bereitgestellt werden.
4) Die Kernschicht ist das Framework selbst und kann selbst eine komplexe Architektur haben. Seine Verantwortung besteht darin, Schnittstellen für die obere Schicht bereitzustellen und die Orchestrierung für den Testlauf und die Berichterstellung bereitzustellen. Es bietet auch häufig eine Low-Level-Implementierung für Schnittstellen, die oberen Schichten ausgesetzt sind.
There’s no one-size-fits-all architecture, so you may suggest many other ways to separate test logic. The provided examples are just a starting point. What’s important is that you should be able outline the architecture of the solution you are working on, and guess if it fits to the project or application. My personal advice would be – stick to the simplest architecture that fits your immediate needs, but try to leave other options open in case you need them.
[1] https://en.wikipedia.org/wiki/Software_framework
[2] https://en.wikipedia.org/wiki/Test_automation#Framework_approach_in_automation
[3] Mark Richards, Muster der Softwarearchitektur. O’Reilly Media, 2015
**Dieser Blog wurde von Google aus dem Englischen ins Deutsche übersetzt.