Softwaretest bei SOA - Teil 2

Softwaretest bei SOA - Teil 2

by Stefan Bregenzer -
Number of replies: 0

Im zweiten Teil dieses Artikel gehe ich auf die Teststufen des V-Modells nach ISTQB ein und beleuchte die Auswirkungen und Potentiale einer SOA auf den Softwaretest.

Komponententest - Wiederverwendung reduziert den Umfang

Diese Tatsache lässt sich in allen Teststufen des V-Modells nach ISTQB ausnutzen. Im Komponententest stellen die Services die Komponenten dar, welche ggf. untereinander kombiniert und mit einem Composition-Controller zu einer Service-Komposition werden. Handelt es sich um SOAP-basierte Webservices können diese mit Standardtesttools wie SoapUI getestet werden. Weiterhin kommen je nach Kritikalität der Services die Whitebox-Testmethoden zum Einsatz, welche die Kernservicelogik testen. Durch die Wiederverwendung werden bereits bestehende Komponenten einen höheren Reifegrad als neue aufweisen. Hier lassen sich daher gut Schwerpunkte vom Testmanagement setzen, da die Wiederverwendung klar ersichtlich ist.

Integrationstest - der standardisierte Vertrag baut Hürden ab

Durch das Prinzip Service standardisierter Vertrag (Service standardized Contract), lose Kopplung von Services und Service Zusammensetzbarkeit (Service composability) wird die Teststufe Integrationstest adressiert. Da der Bedarf nach konfigurierter/programmierter Integration in einer SOA drastisch abnimmt, hat dies Vorteile für einen Integrationstest. Der Vertrag-Zuerst-Ansatz (contract-first-approach) erleichtert die Entwicklung von Platzhaltern (Mock-ups) und Testtreibern, da alle aktuellen und zukünftigen Anforderungen im Vertrag enthalten sind. Dieser Servicevertrag besteht technisch aus WSDL-, XSD und WS-Policy-Dateien und sind beim Aufruf und der Interaktion mit dem Service zwingend vom Konsument (einer temporären Rolle zu Laufzeit) einzuhalten. Zum technischen Vertrag kommt noch ein SLA, welche zusammen den Service-Vertrag bilden. Da die Verträge in den Service-Spezifikationen enthalten sind, kann man hier zeitnah die Testvorbereitungen beginnen. Die Services haben durch die Verträge und des Service Abstraktionsprinzip den Charakter einer Black-Box. Wurde bei der Spezifizierung und Implementierung alles richtig gemacht und ein Maximum an Interoperabilität erreicht, müssen keine aufwändigen Mappings und Datentransformationen getestet werden. Der Einsatz von Webservices mit nicht-proprietärer Kommunikation trägt auch seinen Teil dazu bei, dass ein Integrationstest bei einer qualitativ hochwertigen SOA erleichtert wird.

reife Softwarebestandteile helfen im System- und Abnahmetest

System- und Abnahmetest zeichnen sich durch Black-Box-Verfahren aus. Hier können Äquivalenzklassentest, Entscheidungstabellentest, Grenzwertanalyse, anwendungsfall- bzw. zustandsbasiertem Test genannt werden. Diese sind unabhängig von der Implementierung innerhalb einer SOA oder eines Applikationssilos. Service Orientierung bietet auf diesen Teststufen jedoch auch erhebliche Vorteile. Durch die Wiederverwendbarkeit der Services (Service Reusability), einem standardisiert und normalisierten Inventar aus Services können unter der Voraussetzung einer funktionierenden Governance spätere Projekte viele der agnostischen Services, die mehrere Zwecke unterstützen, in die Lösungsarchitektur einbauen. Dies spart nicht nur Geld und Zeit, sondern die Reduzierung der Eigenentwicklung und die Nutzung von Services mit einem wachsenden Reifegrad und Stabilität hat einen positiven Effekt auf die Softwarequalität in den Ende-zu-Ende-Szenarien. Daher wird mit zunehmender Verbreitung von Service Orientierung im Unternehmen nicht nur die Agilität und das Alignment zwischen Business und IT zunehmen, sondern der Testaufwand wir im Bereich der Fachtests zunehmend weniger bei steigender Qualität zu Testbeginn.

Zusammenfassung

Wie man in den Ausführungen erkennen kann, ist auch der Bereich SOA für einen Softwaretester von steigender Bedeutung. Hier sind zwar technische Änderungen in den unteren Teststufen ersichtlich, jedoch sind die Ziele der SOA im gesamten V-Modell sehr positiv zu bewerten. Sie begünstigen damit nicht nur Entwickler sondern auch Softwaretester bei der täglichen Arbeit. Ich werde dieses Thema daher beständig beobachten.


Tags: