Teststufe Systemtest

TestmanagementDie Welt verändern, ein Bug nach dem anderen…

Systemtest

Image Map
Testen des integrierten Systems in einer, der Produktionsinfrastruktur nahen Umgebung. Testtreiber und Platzhalter werden nicht mehr benötigt. Allerdings steigt der Testaufwand aufgrund der Anzahl der abzudeckenden Systemtestumgebungen. Nicht nur wegen der heterogen Systemtestumgebungen ist es schwieriger und aufwendiger die Tests auf dieser Teststufe zu automatisieren.

Löst ein Systemtestfall einen Datenfluss durch das gesamte System aus, so werden diese Tests auch als End-to-End-Tests bezeichnet.

Manuelle Systemtests können untergliedert werden in
  • Exploratives Testen/Ad-hoc-Testen
  • Sitzungsbasiertes Testen
  • Akzeptanztests.
Beim explorativen Testen handelt es sich um eine erfahrungsbasierte Vorgehensweise. Der Tester hat für diese Art von Tests keine Testspezifikation. Die Testergebnisse hängen stark von dem jeweiligen Tester ab. Die Ergebnisse sind kaum wiederholbar, es werden meist weniger Fehler gefunden.

Beim sitzungsbasierten Testen gibt sich das Testteam ein formale Struktur. Die Testergebnisse werden elektronisch protokolliert. Die Reproduzierbarkeit von Tests ist höher als beim rein explorativen Testen.

Akzeptanztests sind Abnahmetests, die der Kunde oder seine Vertretung durchführt, um das System abzunehmen. Es wird die Frage beantwortet, ob das Produkt seinen Zweck erfüllt und den erwarteten Nutzen bringt. Für den Akzeptanztest können durchaus auch Testfälle aus dem Systemtest verwendet werden.

Systemtestfälle können auch automatisiert werden. Dazu verwendet man beispielsweise Capture & Replay Tools, um alle Bedienschritte aufzuzeichnen und per Knopfdruck ausführen zu können. Nachteilig ist der hohe Änderungsaufwand aufgrund der sich häufig ändernden Bedienersequenzen.
Diese Nachteile können weitgehend durch Keyword-Driven-Testing vermieden werden. Man verwendet hier eine domänenspezifische Testsprache (DSL). Die Testfälle sind weniger änderungsanfällig. Ein Ansatz, um Tests in einer domänenspezifischen Sprache zu formulieren und zu automatisieren ist Behavior-Driven-Test (BDT). Für BDT stehen eine Reihe von Frameworks zur Verfügung.

Fast alle bisher beschriebenen Test hatten funktionale Testfälle als Grundlage. Im Systemtest müssen auch diverse nicht funktionale Aspekte getestet werden. Nicht funktionale Anforderungen beschreiben mit welcher Qualität ein System seine Funktion erbringen soll.
Die nicht funktionalen Merkmalen sind nach ISO 25000 festgelegt. Getestet werden sollten beispielsweise:
  • Langlaufende Tests: Lasttests, Performanztests, Volumentests
  • Manuelle Tests: Robustheit, Hardwareausfall, Recovery
  • Manuelle Tests und intensive Reviews: Benutzerfreundlichkeit, Dokumentation, Wartbarkeit

Wird keine Weiterentwicklung an den Programmen mehr vorgenommen, wird der nächste Build zum Releasekandidaten erklärt. Abschließende Dokumentation und umfangreiche Tests sowie Bugfixing werden durchgeführt.
Im Systemtest steuern wir welche funktionalen und nicht funktionalen Qualitätsmerkmale getestet werden müssen. Ebenso ist je Anforderung/Testfall zu entscheiden, was manuell oder automatisiert getestet werden soll.
U
Teststufe Systemtest
© 2016 Holger Mayer Consulting HMC2