Risikobasiertes Testen: Methode für die Identifikation der richtigen Testfälle

Eine fehlerfreie Software gibt es nicht! Trotzdem wird Software erfolgreich auch in sehr kritischen Systemen eingesetzt. Die Software Entwicklungsprozesse sind aber inzwischen so ausgereift, daß es möglich ist die Fehleranzahl in der Software verlässlich so weit zu reduzieren, dass die Anzahl von Systemfehlern welche Ihre Ursache in der Software haben, so selten geworden sind, dass Sie von der Gesellschaft akzeptiert werden. In diesen sicherheitsrelevanten Projekten werden vor allem spezifikationsbasierten, effizienzbasierten und struktur-basierten Testentwurfsverfahren verwendet. Risikobasiertes Testen spielt in diesem Bereich bisher keine nennenswerte Rolle. Andererseits steigt die Komplexität und der Umfang von Software auch im sicherheitsrelevanten Bereich stark an. Trends wie Industrie 4.0 und autonomes Fahren fördern diese Entwicklung stark. Unter welchen Bedingungen könnte risikobasiertes Testen im sicherheitsrelevanten Bereich zukünftig eine größere Rolle spielen? Wie kann dieses Testentwurfsverfahren verbessert werden, damit die Methode an sich eine weitere Verbreitung finden kann? Der folgende Blogbeitrag diskutiert die Stärken und Schwächen des risikobasierten Testens und erstellt Möglichkeiten vor um die Methode an sich zu verbessern. Einen Überblick über gängige Testentwurfsverfahren finden sich imBeitrag Gegenüberstellung und Bewertung von verschiedenen Testentwurfsverfahren.

Risikobasiertes Testen – Was ist das?

Das ISTQB Glosar definiert den risikoorientierten Test wie folgt: Ein Testvorgehen, bei welchem sich das Management, die Auswahl, die Priorisierung und die Anwendung von Testaktivitäten und Ressourcen an entsprechenden Risikotypen und Risikostufen orientieren.

Stephan Grünfelder beschreibt in seinem Buch Software-Test für Embedded Systems den Risikobasierten Test wie folgt:

Man versucht den Testaufwand so zu lenken, dass dort, wo man Fehler am ehesten erwartet, und dort, wo Fehler am empfindlichsten Wehtun, der meiste Testaufwand investiert wird. An anderer Stelle wird der Testaufwand dagegen reduziert. Zum einen ist für diese Bewertung eine genaue Kenntnis der Anforderungskritikalität notwendig, zum anderen sollte man Daten parat haben, die Rückschlüsse auf die Fehlererwartung zulassen. Das sind zum Beispiel:

Vergleichswerte mit ähnlichen Projekten
Eine hohe Anzahl von bei Code-Review gefundenen, schweren Fehlern in bestimmten Modulen
Eine hohe Fehlerdichte in bereits durchgeführten Systemtests bei bestimmten Funktionen

Diese Beschreibung bezieht sich bei Stephan Grünfelder auf den Software Test. Sie lässt sich aber sehr leicht auf allen anderen Tests, z.B. Systemtests übertragen.

Stärken des Risikobasiertes Testen

Die Stärke des risikobasierten Testentwurfsverfahren liegt darin, dass der Fokus auf dem Finden von Fehlern in den System- bzw. Softwareteilen mit dem größten Risiko liegt. Die Testaufwände, wie

das Erstellen der Testspezifikation
das Erstellen des Testskript für automatische Tests, oder
das Erstellen des Testablaufs für manuelle Tests,
die Testdurchführung
die Auswertung der Ergebnisse

können mit diesem Verfahren effizient gesteuert werden. Vor Erstellung der Testspezifikation, wird basierend auf dem identifizierten Risiko entschieden welche Tests erstellt und durchgeführt werden.

Insbesondere dann, wenn durch transparente Kommunikation des Prozesses der Identifikation und Bewertung der größten Risiken eines Projektes und die daraus abgeleiteten Prioritäten beim Test,

der Projektleiter,
der Kunde,
der System-/Softwarearchitekt und
weitere Verantwortliche

mit einbezogen werden, können exzellente Ergebnisse durch das risikobasierte Testen erzielt werden.

Schwächen des Risikobasiertes Testen

Andererseits liegt die größte Schwäche dieses Testentwurfsverfahren genau bei der Identifikation und Auswahl der zu erstellenden und durchzuführenden Tests, da es keine ausreichende Systematik gibt um die „richtigen“ Tests zu finden. In der Praxis hängt die Qualität der Ergebnisse oft stark von der Person ab, welche die Tests auswählt. Die oben erwähnte transparente Kommunikation, ist nur ein Hilfsmittel, um grobe Fehler bei der Testauswahl zu vermeiden. Ein echter systematischer Ansatz kann dadurch nicht ersetzt werden.

Damit sind dann aber auch die Testergebnisse des risikobasierten Tests oft nur bedingt aussagekräftig. Dies ist insbesondere für den Fall problematisch, wenn die Tests überwiegend positiv sind. Wenn die Testergebnisse überwiegend negativ sind, lässt sich immerhin aus den Ergebnissen ableiten, ob sich die Fehler auf das identifizierte Risiko beziehen, oder nicht. Allerdings stellt dies, insbesondere beim Test großer Systeme einen nicht unerheblichen Aufwand dar.

Systematisierung der Identifikation von Tests

Das zielgenaue, effiziente aufdecken von Fehlern ist die große Stärke des risikobasierten Testens. Um diese Stärke voll zur Geltung zu bringen, müssten also belastbare und nachvollziehbare Daten vorliegen, welche die Auswahl der Tests systematisieren könnten.

Toolgestützte, neue Ansätze versuchen nun genau dies umzusetzen.

Aus dem System- und Software Engineering ist bekannt das Softwareteile welche häufig geändert werden, auch eine erhöhte Fehlerwahrscheinlichkeit besitzen. Daten zur Änderungshäufigkeit werden in folgenden Tools erfasst:
1. Das Versionierungstool (z.B. Git) enthält Daten über die Häufigkeit von geänderten Softwaremodulen.
2. Das Bug-Reporting Tool enthält die geänderten Funktionalitäten und, je nach Tool, ggf. auch die damit verbundenen geänderten Softwaremodule.
Ebenso ist bekannt, daß Funktionalitäten, die nie getestet werden, eine hohe Wahrscheinlichkeit von Fehlern besitzen. Die Abdeckung der Software durch Tests wird erfasst durch:
1. Tools (z.B. VectorCast, Tessy, Parasoft), welche die strukturelle Source Codeabdeckung messen, liefern genau diese Information
2. Tool zur non-intrusiven Systembeobachtung von der Firma Accemic, welche den getesteten Daten- und Kontrollfluss erfassen.
Das Tool Teamscale bietet die Möglichkeit die Daten aus 1.a, 2.a und 2.b zusammenzuführen und darzustellen.
Die Auswertung der Daten des Bug-Reporting Tool benötigt in der Regel die Erstellung eigener, kleiner Skripte

Für das risikobasierte Testentwurfsverfahren bedeutet, dies, dass zunächst Tests mit der höchsten Priorität erstellt und durchgeführt werden. Nach der ersten Durchführung können dann die Daten für die Änderungshäufigkeit, Bugs, Codeabdeckung und Abdeckung der Daten- und Kontrollflüsse ausgewertet werden. Basierend auf den Ergebnissen, können dann systematisch und zielgerichtet Tests ergänzt werden.

Fazit

Risikobasierte Testentwurfsverfahren sind u.a. für folgende Anwendungsszenarien zu empfehlen:

Test von sehr großen, komplexen und nicht sicherheitsrelevanten Software Systemen
Test von nicht sicherheitsrelevanten Software Systemen bei denen erfolgskritische Aspekte nicht effizient mit Requirements definierbar sind (z.B. Software mit komplexen HMIs).
Notwendiges, schnelles Feedback über Änderungen einer Software und die Ausführung aller Tests dauert länger als eine Nacht.
Test von sicherheitsrelevanten Software Systemen welche sich noch in frühen Phasen der Entwicklung befinden

Die Komplexität von technischen Systemen steigt seit Jahren und ein Ende ist nicht absehbar. Der entscheidende Innovationstreiber ist dabei die Software. Sehr leistungsfähige Hardware in Kombination mit komplexer Software sind die Grundlage für Trends wie Industrie 4.0, autonomes Fahren, Smart Home und MKS Mensch-Roboter Kollaboration, um nur einige zu nennen. Software ermöglicht heute die Realisierung von Funktionalitäten mit einer Komplexität, welche mit Elektronik oder Mechanik alleine nie denkbar war. Risikobasiertes Testen wird langfristig vermutlich eine immer wichtigere Rolle spielen. Vorallem gilt das dann besonders, wenn es gelingt den gezeigten Ansatz in der Praxis erfolgreich umzusetzen.

Weitere HEICON Blog Beiträge zum Thema

Ihre individuellen Fragen zum Test Engineering beantworten wir gerne in einem ersten, kostenlosen 30min Beratungsgespräch!
Vereinbaren Sie gleich einen Termin: Eine kurze Mail an info[at]heicon-ulm.de genügt, oder greifen Sie gleich zum Telefonhörer: +49 (0) 7353 981 781 (Mo bis Fr 08:00 – 18:00Uhr).