Architektur und Testbarkeit: Eine Checkliste (nicht nur) für Softwarearchitekten - Teil 2 - isento
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Architektur und Testbarkeit: Eine Checkliste (nicht nur) für Softwarearchitekten – Teil 2
www.architecture4testability.com
www.imbus.de/veranstaltungen/trends-in-testing-2015/
Architektur und Testbarkeit:
Eine Checkliste (nicht nur)
für Softwarearchitekten – Teil 2
Im ersten Teil dieses Artikels, erschienen in der letzten Ausgabe von OBJEKTspektrum, haben wir motiviert,
welchen Nutzen eine Checkliste mit konkreten Testbarkeitsanforderungen und zugehörigen Architektur-
empfehlungen im Projektalltag hat, und den Begriff „(technische) Testbarkeit“ geschärft. Zentrale Elemente
dabei waren die ISTQB-Begriffe „Point of Control“ bzw. „Point of Observation“ sowie die allgemeine Testfall-
Definition (Abbildung 1). Aus dieser abgeleitet haben wir den ersten Bereich der Checkliste zum Thema
„Startzustand und Vorbedingungen herstellen“ entwickelt (Tabelle 1). Analog werden wir nun die Bereiche
„Eingaben ins SUT vornehmen“, „Ausgaben des SUT prüfen“ und „Nachbedingungen prüfen“ behandeln.
Eingaben ins SUT vornehmen 2. Datenbank befüllen klariert) und kann in meisten Fällen durch
Manche Vorbedingungen oder auch Ein- Architektur anders angesiedelt werden,
1. UI-Objekte erkennen und bedienen gaben ins SUT finden am besten direkt in vorzugsweise direkt im SUT.
Automatisierte System- und Akzeptanztests Datenbank-Tabellen statt (z. B. Flags zur
benutzen meistens die Benutzungsoberflä- Simulation, etwa von Gesperrt-Zuständen). 3. Andere Schnittstellen befüllen
che (GUI) als Eingabeschnittstelle. Für eine Viele Architekten finden es ausreichend, Neben GUI und Datenbank kann ein Test-
nachhaltige Automatisierung mit kontrol- wenn eine Persistenzschicht definiert, quali- objekt über weitere spezifische Schnittstel-
lierbaren Wartungskosten ist es unerläss- tätsgesichert und ausreichend dokumentiert len verfügen, in die zu Testzwecken Einga-
lich, dass die UI-Entwicklung von Anfang wird – die Datenbankschema-Definition ben vorgenommen werden müssen.
an eine robuste Objekterkennung gewähr- wird nur noch generiert. Dabei ist es aber Die flexible Anbindung von externen
leistet, da anderenfalls die Anpassungsauf- wichtig zu beachten, dass der Generator Schnittstellen ist immer ein wichtiger As-
wände in der Testautomatisierung rasch durch mehrere Parameter gesteuert wird pekt in der Entwicklung. Einerseits ist es
überhand nehmen können. und ein Austausch des Generators Änderun- unabdingbar, möglichst nah an der frem-
Die Aufgabe des Architekten in diesem gen in der Schemadefinition zur Folge haben den Schnittstellenspezifikation zu bleiben,
Zusammenhang ist einerseits die Prüfung, kann. Um die nötige Stabilität im Projekt zu andererseits erzeugen Änderungen in der
ob die einzelnen Entwickleraufgaben (z. B. gewährleisten und die Dokumentation der Implementierung der externen Schnittstel-
User-Storys oder Use-Cases) so geschnitten Datenbankschema-Definition für alle zu- len, sofern diese überhaupt bereits fertigge-
und verteilt werden können, dass die Ober- gänglich und verständlich zu gestalten, soll- stellt sind, unnötige Störungen im Verlauf.
flächenstruktur eine gewisse Beständigkeit ten Datenbankschemata in einem separaten, Aus Architektursicht ist es empfehlenswert,
hat. Andererseits muss der Architekt über- abstrakten Modell definiert werden. Hier- die Fremdschnittstellen nach Möglichkeit
prüfen, ob die eingesetzte Technologie von für sind sowohl grafische, als auch XML- zu kapseln und selbst implementierte oder
dem Testframework unterstützt wird und basierte Modellierungswerkzeuge, wie z.B. extern bereitgestellte, aber stabile Mock-
die eventuell zur Laufzeit generierten Ele- „Liquibase“, gut geeignet. Durch eine ex- Ups zu nutzen. Die Nutzung der Mock-Ups
ment-IDs für die gleichen Elemente auch terne Schemadefinition hat der Tester dann muss transparent für den Entwickler erfol-
immer gleich bleiben – sich also insbeson- die Möglichkeit, auf eine gültige, verständli- gen und lediglich von der Konfiguration
dere nicht ändern, wenn das Element in der che Dokumentation zuzugreifen und eigene abhängig sein – diese Anforderung legt es
Oberfläche minimal verschoben wird. Viele Skripte und Werkzeuge daran auszurichten. nahe, dem Gesamtsystem ein Framework zu
Technologien, die Oberflächen-Artefakte Funktionalität, die in Datenbanksystemen Grunde zu legen, das über die Konfigurati-
generieren (z. B. aus einem Objekt- oder realisiert wird (z. B. Trigger und Stored on die Anbindung/Bereitstellung und Nut-
Datenmodell), bieten keine Möglichkeit, Procedures), erschwert den Test (nebenbei zung der Module/Schnittstellen erlaubt (vgl.
solche konstanten IDs zu erzeugen. wird das Datenbanksystem zum SUT de- TU-Abstraktionsschicht in Abbildung 2).
Sollte die im Projekt definierte Technologie
es erlauben, die IDs für die Oberflächenele-
mente selbst zu definieren, muss im Entwick-
lungsteam klar kommuniziert werden, dass
diese IDs eine besondere Bedeutung haben
und nicht ohne Grund geändert werden dür-
fen. Maßnahmen zur Einhaltung sind: Klare
Kommunikation der Auswirkungen der Än-
derung an die Entwickler, regelmäßige Re-
views, statische Code-QS mit der Überprü-
fung, ob die IDs wie definiert gesetzt sind. Abb. 1: Genereller Aufbau eines Testfalls.
72
www.objektspektrum.de
onsschicht (z. B. JPA in JEE-Applikationen)
die Unit-Tests die Datenbankzugriffe mit-
testen sollten oder nicht. Grundsätzlich gilt,
dass die Abstraktionsschicht eine bereits
vielfach getestete Komponente darstellt
und ihre Funktionalität nicht mehr getestet
werden muss. Das bedeutet, dass es aus-
reicht, beim Persistieren von Daten via Ab-
straktionsschicht wieder über die Abstrak-
tionsschicht zu überprüfen, ob diese Daten
korrekt persistiert wurden. Die alternative
Vorgehensweise – Überprüfung der erfolg-
ten Persistierung der Daten direkt in der
Datenbank (ohne die Abstraktionsschicht)
– wird nicht empfohlen, da dies die Unit-
Tests abhängig von der Infrastruktur macht
und ihre Portierung mit zusätzlichem Auf-
wand verbunden ist.
In speziellen Fällen ist es aber unabdingbar,
Daten direkt in der Datenbank zu überprü-
fen – sei es das Testen der Konfiguration
Abb. 2: Testbegriffe aus der Architektur-Perspektive. der Caching-Mechanismen oder der Konfi-
guration der Abstraktionsschicht selbst: In
Frameworks mit Dependency-Injection-Un- welche Applikationsmodule welche Pakete jedem Projekt müssen entsprechende Tests
terstützung und Inversion of Control bieten importieren bzw. nutzen (siehe Tabelle 2). definiert sein. Damit die enge Bindung an
hier hervorragende Unterstützungsmecha- die Datenbank nicht zum Nachteil wird,
nismen, insbesondere auch wegen der Au- Ausgaben des SUT prüfen wird empfohlen, spezielle Werkzeuge ein-
tomatisierbarkeit der Konfigurationseinstel- zusetzen, die den Zugriff zwar ohne die
lungen je nach Testumgebung oder Testziel. 1. UI-Objekte erkennen und auslesen Abstraktionsschicht realisieren, aber eigene
Dabei muss sichergestellt werden, dass die Hier gelten dieselben Architektur-Maßnah- Mechanismen anbieten, um unabhängig
Entwicklung nicht „ausbricht“ und an- men wie bei „UI-Objekte erkennen und be- von den Datenbank-Treibern den Zugriff
fängt, fremde Schnittstellen direkt, d.h. dienen“. zu realisieren und die Daten auszulesen.
unter Umgehung der Abstraktionsschicht, Zuletzt sollte noch darauf hingewiesen wer-
zu nutzen. Dies kann mit relativ wenig Auf- 2. Datenbank auslesen den, dass die Datenbanktabellen-Struktur
wand durch statische Codeanalyse erreicht Entwickler sind zuweilen uneinig darüber, und die Klassenstruktur der Persistenz-
werden, indem regelmäßig überprüft wird, ob in Projekten mit Datenbank-Abstrakti- schicht durchaus Unterschiede aufweisen
Tabelle 1: Architekturmaßnahmen im Kontext „Startzustand und Vorbedingungen herstellen“.
02/2016 73
Architektur und Testbarkeit: Eine Checkliste (nicht nur) für Softwarearchitekten – Teil 2
Tabelle 2: Architekturmaßnahmen im Kontext „Eingaben ins SUT vornehmen“.
können. So kann die Tabellenstruktur sich zu protokollieren sind. Ein einheitliches Log- imstande, Protokolldateien auf jedem Kno-
ändern, obwohl die Klassenstruktur im enge- ging-Framework über Komponenten hinweg ten im Cluster automatisiert in eine zentrale
ren Sinne identisch bleibt (z.B. nur durch die vereinfacht die Handhabung und die Ver- Referenzliste einzutragen, sodass kein Kno-
Änderung der Konfiguration oder der An- waltung und die Konfiguration für das Log- ten versehentlich vergessen wird.
notationen). Solche Sonderfälle sind bei der ging kann so außerdem zentralisiert werden. Zuletzt sei darauf hingewiesen, dass die
Gestaltung der Abfragen zu berücksichtigen. In vielen Projekten mit Bezug auf persönliche Konfiguration des Formats der Protokollaus-
Einen guten Funktionsumfang für die Test- Daten werden besondere Vorschriften bezüg- gaben nicht weniger wichtig ist. Einerseits
unterstützung mit Datenbankzugriff bieten lich Protokolldaten definiert. Beispielsweise müssen die Protokollausgaben möglichst alle
Frameworks wie „DBUnit“ im Java-Um- muss es grundsätzlich vermieden werden, notwendigen Details liefern, damit die Feh-
feld und „ndbunit“ in der .NET-Welt. personenbezogene Daten zu protokollieren. leranalyse möglich ist. Andererseits ist aber
Das erleichtert auch den Zugriff auf die darauf zu achten, dass die Protokolldateien
3. Log- und Protokoll-Dateien auslesen Log-Dateien, da keine vorgelagerten Verwal- nicht allzu groß werden – die Bereithaltung
Manche Testergebnisse sind aus Logfiles tungsprozesse wie Freigaben notwendig sind. der Protokolldaten für mehrere Tage kann
auszulesen, da das System hier die zu prü- Aktuelle Softwaresysteme werden meist auf für einige Großsysteme bereits zu einer Her-
fende Information ablegt. mehrere Knoten (z. B. im Cluster) verteilt. ausforderung werden. Und auch der Test be-
Eine durchdachte Protokollierung kann Es ist besonders wichtig darauf zu achten, nötigt Informationen, wie er die zu prüfende
nicht nur bei der Fehlersuche im System hel- dass entweder jeder Knoten für sich so weit Information (z.B. automatisiert) findet.
fen, sondern somit auch zur Vereinfachung abgeschlossen ist, dass die Fehlersuche in-
der Testausführung beitragen. In speziellen nerhalb des Knotens stattfinden kann, oder 4. Andere Schnittstellen auslesen
Situationen können Log-Einträge als Nach- das Logging-Framework so zu konfigurie- Hier gelten dieselben Architekturmaßnah-
weis für die erfolgreiche Ausführung einer ren, dass die Protokolleinträge auf unter- men wie bei „Andere Schnittstellen befül-
Aktivität mit externen Schnittstellen aus- schiedlichen Systemen einem Ereignis zu- len“ (siehe Tabelle 3).
reichen, wenn z. B. die detaillierte Analyse geordnet werden können. Hierfür benötigt
der Zustände in externen Schnittstellen zu man spezielle Werkzeuge zur Zusammen- Endzustand und
aufwändig ist. führung mehrerer Protokolldateien und Nachbedingungen prüfen
Bei der Definition der Richtlinien für Pro- zur Analyse. Damit die Zusammenführung
tokollierung ist darauf zu achten, dass sich möglich wird, müssen diverse Protokollein- 1. Zustand des SUT auslesen
eine nachvollziehbare Gewichtung der Log- träge eines Ereignisses einander zugeordnet Analog zur kontrollierten Erzeugung eines
Ausgaben für die Log-Stufen ergibt. Auf werden können. Das kann auf einfache Startzustands zu Testbeginn muss der Test
den Produktivsystemen wird meistens Log- Weise durch die Ausgabe der ID des Initi- erkennen, in welchem Zustand sich das SUT
Stufe „Info“ oder „Warn“ aktiviert – d.h. alereignisses, durch Thread-ID oder durch nach Abschluss des Tests befindet, um prü-
im Entwicklungsteam muss kommuniziert Framework-interne Kontext-ID erfolgen. fen zu können, dass ein Soll-Zustand wie
sein, welche Aktionen mit dieser Log-Stufe Einige Frameworks sind darüber hinaus verlangt tatsächlich erreicht wurde. Aber
Tabelle 3: Architekturmaßnahmen im Kontext „Ausgaben des SUT prüfen“.
74
www.objektspektrum.de
Tabelle 4: Architekturmaßnahmen im Kontext „Nachbedingungen prüfen“.
nicht nur für den Test, sondern auch für die
Wartung des Systems ist es notwendig, diese Literatur & Links
Zustände eindeutig identifizieren zu können.
Als Voraussetzung zur Erfüllung dieser An- [Bra15] C. Brandes, S. Okujava, J. Baier, Architektur und Testbarkeit: Eine Checkliste (nicht
forderung müssen die Systemzustände do- nur) für Softwarearchitekten – Teil 1, in: OBJEKTspektrum 1/2016
kumentiert und nachvollziehbar sein. Au- [Fow02] M. Fowler, Patterns of Enterprise Application Architecture, Addison-Wesley, 2002
ßerdem ist es essenziell, geeignete PoOs pro [Hei10] Heise Developer, Podcast: SoftwareArchitekTOUR – Podcast für den professionellen
Zustand bereitzustellen, damit der Tester Softwarearchitekten, Folge 24: „Testing & Softwarearchitektur“, 2010, siehe:
den Zustandsübergang verifizieren kann. http://www.heise.de/developer/artikel/Episode-24-Testing-Softwarearchitektur-1080236.html
Eine Alternative wäre die explizite Proto- [Ise] Isento GmbH, Architektur und Testbarkeit: Eine Checkliste (nicht nur) für Software-Ar-
kollierung des erreichten Systemzustands. chitekten, siehe: http://www.architecture4testability.com
[IST15] International Software Testing Qualifications Board (ISTQB), Glossary, 2015, siehe:
2. Fremdkomponenten in http://www.istqb.org/downloads/glossary.html
der Testumgebung auslesen [Jun02] S. Jungmayr, Design for Testability, 2002, siehe:
Zuweilen kann es aus Testsicht erforderlich http://www.jungmayr.de/Publikationen/CONQUEST02_jungmayr.pdf
sein, Endzustand und Nachbedingungen [Tes] Testtool Review, Toolübersicht zu Testdatenmanagement, siehe:
auch von externen Komponenten ausle- https://www.testtoolreview.de/de/toolkategorien/item/68-testdatenmanagement
sen und prüfen zu können – wobei das [Zil12] F. Zilberfeld, InfoQ, Design for Testability – The True Story, 2012, siehe:
eher die Ausnahme ist, da es nicht Teil des http://www.infoq.com/articles/Testability
Testauftrags sein sollte, die Korrektheit
angebundener Partnersysteme mitzutesten.
Ansonsten gelten dieselben Architektur- wurde nach unserem Kenntnisstand vorher als Startschuss – idealerweise wird sie künf-
Maßnahmen wie bei „Fremdkomponenten noch nie die Brücke zu konkreten Testbar- tig von Architekten genutzt und ergänzt,
befüllen“ (siehe Tabelle 4). keitsnotwendigkeiten geschlagen und dabei verbessert und erweitert. Deshalb haben wir
der Versuch einer umfassenden Sammlung sie auf einer eigenen Seite publiziert und Ka-
Zusammenfassung und Ausblick unternommen. Hierin sehen wir den größten näle für Erweiterungswünsche eingerichtet
Wie wir gesehen haben, sind die diskutierten Nutzen unserer bisherigen Arbeit. (vgl. [Ise]). Der weiteren Entwicklung sowie
Maßnahmen für Architekten allesamt wohl- Folglich betrachten wir die Checkliste (siehe konstruktivem Feedback jeder Art sehen
bekannt und keine Geheimwissenschaft. Nur Tabellen 1 bis 4) in der aktuellen Form nur wir mit Spannung entgegen. ||
Die Autoren
|| Dr. Christian Brandes || Dr. Shota Okujava || Dr. Jürgen Baier
(christian.brandes@imbus.de) (shota.okujava@isento.de) (juergen.baier@modellar.de)
arbeitet als leitender Berater und Trainer für ist geschäftsführender Gesellschafter der Isento ist geschäftsführender Gesellschafter der
die imbus AG. Aktuelle Arbeitsthemen sind GmbH sowie als Architekt und Berater für Java- Modellar GmbH und als agiler Coach, Architekt
Testprozess-Analysen, agiles Testen sowie Enterprise-Technologien in Großprojekten tätig. und Berater im JEE-Umfeld tätig. Neben agilen
Schnittstellen des Tests zu anderen IT-Disziplinen. Seine Spezialthemen sind SOA, modellgetriebene Entwicklungsframeworks beschäftigen ihn vor-
Softwareentwicklungsprozesse sowie Integra- rangig CI/CD und die Synchronisation verteilter
tionstechnologien. Datenbestände.
02/2016 75Sie können auch lesen
