Software-Zuverlässigkeit
Software-Zuverlässigkeit ist definiert als „Wahrscheinlichkeit der fehlerfreien Funktion eines Computerprogramms 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 statistische Analysen auf der Basis von umfangreichen Tests durchgeführt. In der Theorie gibt es jedoch auch Techniken, die von der statischen Analyse des Computerprogramms 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 durchgeführt werden.
- Komponenten- bzw. Integrationstest: Die hier ermittelbaren Testfälle zielen auf die Ansteuerung aller Schnittstellen zwischen Komponenten ab. Mittels Model-based-testing können hierfür Testfälle für alle Schnittstellen und Subsysteme systematisch aus dem Modell abgeleitet werden.
- 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 bezogen 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, ist eine hohe Anzahl verschiedener Testfälle und die wiederholte Durchführung von Regressionstests notwendig. Werden 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.