Software-Zuverlässigkeit

Begriff und Messung

Software-Zuverlässigkeit ist definiert als die „Wahrscheinlichkeit der fehlerfreien Funktion eines Computerprogramms in einer spezifizierten Umgebung in einer spezifizierten Zeit“. Sie ist damit ein objektives, messbares oder schätzbares Kriterium der Softwarequalität und gehört zu den Software-Metriken.

Zuverlässigkeitsmetriken beruhen grundsätzlich auf der Häufigkeit von Fehlern im Verhältnis zur Anzahl der ausgeführten Testfälle. Für statistisch aussagekräftige Ergebnisse sind umfangreiche Tests erforderlich. In der Theorie existieren außerdem Verfahren, die nicht von der Programmausführung, sondern von der statischen Analyse des Programms oder seines Modells ausgehen.

Arten von Testfällen

Welche Testfälle relevant sind, hängt vom Fokus und von der Granularität der Software-Under-Test (SUT), also der zu prüfenden Software, ab.

• Beim (Sub-)Systemtest kommen Black-Box-Verfahren zum Einsatz. Sie leiten typische Testfälle aus dem Lastenheft ab, ohne den inneren Entwurf oder die Realisierung zu betrachten. Besonders wichtig sind Randwerte und unplausible Werte. Stresstests prüfen außerdem das System im Hinblick auf Daten- und Nutzungsmengen sowie Geschwindigkeit.

• Komponenten- und Integrationstests prüfen die Ansteuerung aller Schnittstellen zwischen den Komponenten. Beim Model-based Testing werden die Testfälle für Schnittstellen und Subsysteme systematisch aus einem Modell abgeleitet.

• Unittests untersuchen einzelne Softwareeinheiten. White-Box-Verfahren berücksichtigen dabei deren konkrete Realisierung und leiten Testfälle für Extremwerte, Funktionen sowie eine hohe Branch- oder sogar Pfad-Abdeckung ab. Branch-Abdeckung bezeichnet die Prüfung möglichst aller Programmverzweigungen; Pfad-Abdeckung bezieht sich auf die möglichen Ausführungspfade.

Zu jedem Testfall gehört ein Akzeptanzkriterium, das festlegt, welches Ergebnis als korrekt gilt. Dieses Kriterium muss sich auf die zugehörige Spezifikation beziehen. Andernfalls können systematische Widersprüche zwischen den Testfällen und der Software-Spezifikation entstehen.

Wiederholungen und Umgebungsvariation

Statistische Aussagen über die Zuverlässigkeit setzen eine große Anzahl unterschiedlicher Testfälle und wiederholt ausgeführte Regressionstests voraus. Regressionstests prüfen, ob die Software nach Änderungen weiterhin wie vorgesehen funktioniert.

Bei Wiederholungen müssen die Umgebungsbedingungen systematisch verändert werden, ohne dass diese Variation mit dem jeweiligen Testfall zusammenhängt. Unter exakt identischen Bedingungen liefert deterministische Software stets dasselbe Ergebnis. Bei hinreichend komplexen Systemen ist diese Determiniertheit jedoch schnell nur noch theoretisch. Wiederholte Tests mit unabhängig variierter Umgebung können dann signifikante Ergebnisse liefern.

Automatisierung und stufenweise Prüfung

Die große Zahl notwendiger Tests lässt sich praktisch nur mithilfe von Testautomatisierung bewältigen. Sie muss die Systemebene und einzelne Items umfassen und bis zu den Software-Units, also den kleinsten geprüften Softwareeinheiten, verfeinert werden.

Zuverlässigkeitstests auf Systemebene sind nur sinnvoll, wenn zuvor auch die Elemente der jeweils nächsten statischen Verfeinerungsstufe getestet wurden: Subsysteme, Komponenten und Units. Entwickler müssen den Testern deshalb für jede Ebene getrennt eine Testumgebung, Testtreiber und Testfälle bereitstellen. Ein Testtreiber ist dabei die Software, die den Prüfling für den Test aufruft oder steuert. Wegen dieses mehrstufigen Aufwands ist Zuverlässigkeit ein anspruchsvolleres Ziel als die reine Gefährdungsfreiheit („Safety“).

Spezifikation und Entwurfsprozess

Der Entwurfsprozess sollte ermöglichen, das Lastenheft und andere Spezifikationen der konstruktiven Seite anhand der Akzeptanzkriterien von Testfällen zu verfeinern. In der Praxis beruhen scheinbare Softwarefehler teilweise lediglich auf ungenauen oder widersprüchlichen Anforderungen.

Die Formulierung von Testfällen und Akzeptanzkriterien dient deshalb nicht nur der Prüfung fertiger Software. Sie macht regelmäßig auch eine Präzisierung der jeweiligen Spezifikation erforderlich und trägt dazu bei, Anforderungen und erwartete Ergebnisse konsistent aufeinander abzustimmen.

Einbindung in die Software-Integration

Automatisierte Tests können schrittweise in die Software-Integration eingebaut werden. Dazu wird in den Integrationsskripten, etwa „build“ oder „makefile“, ein Testprotokoll als „target“ eingerichtet. Dieses Ziel wird aus dem Aufruf des Testgenerators, den zu prüfenden Zwischen-Artefakten und den Testfällen abgeleitet. Als Zwischen-Artefakte nennt der Artikel „OBJ“, „lib“, „OCX“, „DLL“ und „JAR“.

Regressionstests auf Systemebene benötigen viel Rechenzeit. Sie sollten daher entweder vom übrigen Integrationsablauf abgespalten oder parallel ausgeführt werden. In diesem Fall kann das Produkt beziehungsweise System technisch bereits verfügbar sein, während die Regressionstests noch laufen.