Software-Zuverlässigkeit

Software-Zuverlässigkeit ist definiert als „Wahrscheinlichkeit der fehlerfreien Funktion eines Computer-Programms in einer spezifizierten Umgebung in einer spezifizierten Zeit“ ^[1]. Damit gehört Software-Zuverlässigkeit zu den objektiven, messbaren oder schätzbaren Kriterien der Softwarequalität und gehört somit zu den Software-Metriken. Die Metriken für Zuverlässigkeit von Software basieren im Prinzip auf Fehlerhäufigkeiten, relativ zur Anzahl der ausgeführten Testfälle. Grundsätzlich werden also meist statistische Analysen auf der Basis von umfangreichen Tests angestellt werden. In der Theorie gibt es jedoch auch Techniken, die von der statischen Analyse des Software-Programms oder von dessen Modell ausgehen.^[2]

Testfälle

Relevante Testfälle hängen vom Fokus und von der Granularität der Software-Under-Test (SUT) ab:

• (Sub)Systemtest: Black Box-Verfahren ermitteln ohne Ansehen des Designs oder der Realisierung aus dem Lastenheft typische Testfälle, wobei Randwerte und unplausible Werte eine besondere Bedeutung haben. Weiterhin können Stresstests unter den Gesichtspunkten der Mengengerüste und der Geschwindigkeit durch Testfälle realisiert werden.

• Komponenten-/Integrationstest: Die hier ermittelbaren Testfälle zielen auf die Ansteuerung aller Schnittstellen zwischen Komponenten ab. Model-based-testing schlägt dazu vor, Testfälle für alle Schnittstellen und Subsysteme systematisch aus dem Modell abzuleiten.

• Unittests: White Box-Verfahren analysieren die Realisierung von Units und leiten Testfälle im Hinblick auf Extremwerte, Funktionen und eine hohe Branch- oder gar Pfad-Abdeckung ab.

Neben dem Testfall an sich ist dem jeweils zugehörigen Akzeptanzkriterium besondere Aufmerksamkeit zu widmen: Die Akzeptanz muss in jedem Fall auf die zugehörige Spezifikation abbildbar sein, da ansonsten systematische Inkonsistenzen zwischen Testfällen und Software-Spezifikation auftreten können.

Regression und Wiederholung

Um statistische Aussagen für eine Metrik zu erhalten, braucht man sehr viele verschiedene Testfälle und die wiederholte Durchführung von Regressionstests. Wenn man die Testfälle wiederholt ausführt, ist eine systematische, jedoch mit dem Testfall unkorrelierte, Variation der Umgebungsbedingungen wichtig, denn bei exakt identischen Umgebungsbedingungen wird wegen der Determiniertheit von Software stets das identische Ergebnis auftreten. Bei hinreichender System-Komplexität ist die Determiniertheit jedoch schnell bloße Theorie und die Wiederholung mit unabhängig variierender Umgebung bringt signifikante Ergebnisse.

Testautomatisierung

Um die Vielzahl von Tests überhaupt praktikabel durchführen zu können, benötigt der Tester eine Testautomatisierung auf der Ebene von System und Items, bis zur Verfeinerung auf Software-Units. Zuverlässigkeitstests auf einer System-Ebene sind nur dann sinnvoll, wenn die Items der nächsten statischen Verfeinerung (Subsysteme, Komponenten, Units) schon zuvor auf Zuverlässigkeit getestet wurden. Dazu müssen Entwickler den Testern - für jede Ebene separat - Testumgebung, Testtreiber und Testfälle bereitstellen. Insofern ist Zuverlässigkeit ein aufwändigeres Ziel, als die reine Gefährdungsfreiheit („Safety“).

Anmerkungen zum Entwurfsprozess

Der Entwurfsprozess sollte unbedingt die Möglichkeit vorsehen, das Lastenheft und andere Spezifikationen der „konstruktiven Seite“ im Hinblick auf vorhandene Akzeptanzkriterien von Testfällen zu verfeinern, da die Praxis zeigt, dass sich scheinbare „Fehler“ lediglich aus ungenauen oder inkonsistenten Anforderungen ergeben. Aus diesem Grund wird der Prozess der Formulierung von Testfällen und Akzeptanzkriterien regelmäßig eine Präzisierung der jeweiligen Spezifikation erforderlich machen.

Test als Teil der Integration

Technisch können automatisierte Tests als Teil der Software-Integration sukzessive eingebaut werden. Dabei wird in die Integrationsskripten („build“, „makefile“) der Software-Integration ein Testprotokoll als „target“ etabliert, das aus dem Aufruf des Testgenerators, der zu testenden Zwischen-Artefakte („OBJ“, „LIB“, „OCX“, „DLL“, „JAR“) sowie den Testfällen abgeleitet ist. Die Regressionstests auf Systemebene sollten aus Gründen der Rechenzeit allerdings entweder abgespalten oder parallelisiert werden. Dabei wäre das Produkt (System) bereits während der noch laufenden Regressionstests technisch verfügbar.

Einzelnachweise

1. ↑ J.D. Musa, A. Iannino, and K. Okumoto, Engineering and Managing Software with Reliability Measures, McGraw-Hill, 1987
2. ↑ Doron Peled, Bell Labs/Lucent Technologies, Murray Hill, NJ, USA Publisher: Springer-Verlag , 0-387-95106-7

 

Siehe auch: Entwicklungsstadium (Software)