Lesezeit 6 min
Während die Qualität einer Software früher dem «Zufall» überlassen wurde, wird heute immer öfter ein minimales Qualitäts-Level gefordert. Dies ist zum Beispiel durch Standards zu funktionaler Sicherheit oder Software-Security der Fall.
Deshalb sind etablierte Qualitäts- sowie Safety- oder Security-Standards eine gute Quelle für Massnahmen zum Erreichen der geforderten Software-Qualität.
Grundsätzlich können die Software-Qualitäts-Massnahmen in folgende Kategorien unterteilt werden:
- Strukturierte Spezifikation und Design
- Guidelines zu Design und Codierung
- Verifikations- und Validations-Methoden; d.h. Reviews, Analysen und Tests
Diese Kategorien zeigen, dass Software-Qualität nicht allein durch Verifikation oder gar nur durch Tests erreicht werden kann. Dennoch ist die Verifikation ein zentraler Bestandteil der umzusetzenden Massnahmen.
In diesem Beitrag wollen wir uns deshalb die Verifikations- und Validations-Methoden genauer anschauen.
Wie erreiche ich, dass die resultierende Qualität meiner Software nicht dem Zufall überlassen ist? Reicht es aus, wenn die Software-Entwickler informell prüfen, ob sich die Software wie erhofft verhält?
Ich beantworte in diesem Blog folgende Fragen:
Welche Strategien dienen der Prüfung der Software? Validation und Verifikation
Was bedeutet Validation?
Die Software wird im vorgesehenen Umfeld wie vorgesehen verwendet. Die Validierung zeigt, ob die Software die vom Benutzer gestellten Erwartungen an die Funktion erfüllt.
Die Validierung sollte "strukturiert", d.h. geplant nach vorher definierten Kriterien, erfolgen, z.B.:
- Tests durch Entwickler aufgrund von angenommenen Benutzer-Erwartungen (z.B. strukturiertes Durchführen aller "User-Stories")
- Kontrollierte Feldtests: gezielt ausgewählte Benutzer (Beta-Tester) verwenden die Software respektive das System. Wichtig ist hier die strukturierte Erfassung des Feedbacks.
Was bedeutet Verifikation?
Die Verifikation prüft, ob die Software die definierten Anforderungen korrekt und vollständig erfüllt.
Die Verifikation sollte "strukturiert", d.h. geplant mit vorher definierten Kriterien, erfolgen, z.B.:
- Tests durch Entwickler aufgrund von auf Anforderungen basierenden Test-Cases
- Analysen durch Entwickler; zum Beispiel Daten-Fluss oder Kontroll-Fluss-Analyse
- Reviews durch Entwickler mit Hilfe von vordefinierten Kriterien (Guidelines, Checklisten)
Wieso machen wir Reviews und Analysen?
Tests allein reichen nicht aus, um eine gute Software-Qualität sicherzustellen. Software ist generell zu komplex, als dass alle Fehler über Tests gefunden werden können. Deshalb muss zusätzlich auch die strukturierte, korrekte Erstellung der Software sichergestellt werden. Dies geschieht unter anderem durch Reviews oder Analysen während Design und Implementation der Software.
Beachten Sie: wichtig sind auch Vorgaben (Guidelines) zum Design und der Implementation. Diese sind aber nicht Teil der Verifikation oder Validation und liegen somit ausserhalb des Rahmens dieses Artikels.
Es gibt unterschiedlich strukturierte und formalisierte Vorgehensweisen für Reviews:
- Walk Through: Mehrheitlich unstrukturierte und wenig formalisierte Vorstellung eines Arbeitsproduktes durch dessen Autor mit dem Ziel Feeback bezüglich Fehler zu bekommen. Der Walk Through bedarf wenig Aufwand, seine Effizienz ist aber stark von der Präsentation des Autors abhängig.
- Peer-Review: Prüfung eines Arbeitsproduktes durch einen "Peer".
- Inspektion (z.B. Fagan Inspection): Strukturierte Vorgehensweise, um Arbeitsprodukt im Team zu prüfen.
Nicht weniger wichtig als die Vorgehensweise ist die strukturierte Steuerung der zu prüfenden Aspekte. Dies geschieht z.B. durch:
- Review-Guidelines
- Checklisten mit Checks zu diversen zu prüfenden Aspekten
Auf welchen Ebenen wird getestet?
Dass Software-Tests zur Sicherstellung der Qualität notwendig sind, ist wohl jedermann klar. Aber auf welchen Ebenen der Software-Entwicklung Tests sinnvoll oder gar notwendig sind, führt oft zu längeren Diskussionen.
Unit-Tests
Unit Tests prüfen kleinste Teile der Software einzeln. Dadurch ist es meistens möglich, dass beim Test alle Code-Teile durchlaufen werden (siehe auch unten: Code-Coverage). Typischerweise wird unter Unit-Test das Testen von einzelnen Funktionen verstanden.
Abhängig von der Anzahl der Hierarchiestufen, auf welchen Tests durchgeführt werden, kann aber ein anderer Ansatz sinnvoll sein: anstatt einer einzelnen Funktion deckt ein Test-Case gleich mehrere Funktionen inklusive deren Zusammenspiel ab. So können bereits auf unterster Test-Ebene erste Integrations-Probleme entdeckt werden.
Unit Tests sollten in der Regel mit speziell dazu entwickelten Tools durchgeführt werden. Gründe dafür sind:
- Tools erlauben ein adäquates Management von einer sehr hohen Anzahl an Test-Cases
- Tools können “Verunstaltung” des produktiven Codes durch Test-Support Code verhindern
(Stichwort: Code-Instrumentierung durch Tools zur Durchführung von White-Box Tests) - ev. weitere Prozess-Anforderungen wie z.B. das Ermitteln der Code-Coverage
Für Embedded Software ist es grundsätzlich sinnvoll, wenn Software Tests auf der Ziel-Hardware durchgeführt werden. Besonders wichtig ist dies aber vor allem bei den Integrations- und Software-Tests (siehe folgende Kapitel). Abhängig von der benötigten Qualität kann Unit-Testing auf dem Entwicklungs-System (PC) auch ausreichend sein.
Integrations-Test
Ein Teil der Software, mehrere integrierte Units, werden geprüft. Dabei wird die korrekte Zusammenarbeit der Units an deren Schnittstellen verifiziert.
Test der gesamten Software
Die Software wird als Ganzes getestet. D.h. wir prüfen, ob die Software bei definierten Eingaben das korrekte Verhalten zeigt, z.B. die korrekten Ausgaben macht.
Was sollte man beachten? Wichtige Überlegungen beim Software-Test
Black oder White Box Testing
- Black Box Testing: Das Testen beschränkt sich auf das Anlegen von Eingabewerten und die Beurteilung der Ausgabewerte der Software.
- White Box Testing: Block Box Testen ist nicht in jedem Fall mit vernünftigem Aufwand möglich. White Box Testen (Beeinflussung oder Prüfung Software-interner Information) kann in diesem Fall weiterhelfen.
Qualität der Test-Cases
Die Definition der Test-Cases von Software-, Integrations- oder Unit-Tests ist nicht trivial. Die Qualität eines Tests ist am Ende stark vom "Engineering-Judgement" des Autors abhängig.
Es gibt aber Methoden, welche eine strukturierte, wiederholbare Erstellung und Beurteilung der Qualität von Tests erlauben:
Strukturierte Definition von Test-Cases aufgrund Guidelines/ Check-Listen
Die Tests werden aufgrund von Vorgaben definiert. Diese geben zum Beispiel die zu prüfenden Aspekte vor. Beispiele wären:
- Definiere Test-Cases aufgrund einer Analyse der funktionellen Anforderungen (Requirements)
- Definiere Test-Cases, um Funktion bei allen erwarteten Bedingungen sicherzustellen (Stichworte: Boundary Values, Equivalence Classes)
- Definiere Test-Cases, um die Robustheit sicherzustellen (z.B. Fehler in der Software oder durch Benutzer, unerwartete Umgebungsbedingungen)
- Definiere Test-Cases aufgrund erwarteter Fehler (kritische Aspekte aufgrund von Erfahrung testen)
Analyse der Anforderungs-Abdeckung
Etabliere Traceability von Test-Cases zu Anforderungen, um die Abdeckung der Anforderungen durch Tests strukturiert zu analysieren.
Analyse der Code-Abdeckung (Code Coverage)
Moderne Test-Tools erlauben die Erfassung der Code-Abdeckung während der Test-Durchführung. Mit dieser Analyse kann somit geprüft werden, ob die definierten Test-Cases die gesamte umgesetzte Funktionalität prüfen oder nicht.
Abhängig von der Art der Tests und der gewünschten Qualität können unterschiedliche Metriken verwendet werden, z.B.:
- Call- und Caller-Coverage: Anteil der aufgerufenen Funktionen respektive der Funktions-Aufrufe während der Test-Durchführung
- Statement-Coverage: Anteil der durchgeführten Statements/ Befehle der Software während der Test-Durchführung
- Decision-Coverage: Anteil der getroffenen Entscheidungen während der Test-Durchführung
- Modified condition/decision coverage (MC/DC): Anteil der aktiven Konditionen für alle Entscheidungen während der Test-Durchführung
Das Sicherheitsnetz - die Kombination macht es aus!
Grundsätzlich muss davon ausgegangen werden, dass beim Erstellen von Software Fehler geschehen und dass auch beim Umsetzen einer Verifikations-Methode Fehler übersehen werden.
Deshalb ist es sinnvoll, durch den Einsatz von mehreren Verifikations-Methoden auf unterschiedlichen Ebenen (z.B. Tests auf Unit-Level und Tests der Gesamt-Software) ein "Sicherheitsnetz" zu haben, das potenzielle Fehler aufdecken kann. Abhängig von der benötigten Qualität kann dieses "Sicherheitsnetz" grob- oder feinmaschig sein.
Wie wähle ich die richtigen Verifikationsmethoden für mein System respektive Projekt?
Qualitätsstandards (z.B. CMMI) oder Safety- und Security-Standards liefern Informationen, welche Methoden für welche Qualitäts-Anforderungen sinnvoll sind.
Abhängig von der benötigten Software-Qualität wird ein geeignetes Set von Verifikations-Methoden aufgrund deren Kosten-Nutzen Verhältnis gewählt.
Die folgende Auflistung zeigt etablierte Prinzipien sortiert nach typischem Kosten-Nutzen Verhältnis:
- Test durch kontrollierte Verwendung der Software (Validationstests, Feldtests)
- Tests der gesamten Software
- Anforderungs-basiertes Testen der Funktion
- Boundary Condition, Equivalence Classes und Performance-Tests
- Robustness Tests
- Design Analysen und Reviews
- Software-Integrations-Tests (Klassen von Tests analog zu Tests der gesamten Software oben)
- Code Reviews
- Unit Tests (Klassen von Tests analog zu Tests der gesamten Software oben)
Viel Spass beim Testen, Verifizieren und Validieren!
Matthias Eggenberger
Haben Sie zusätzliche Fragen? Haben Sie eine andere Meinung? Wenn ja, mailen Sie mir oder kommentieren Sie Ihre Gedanken unten!
Autor
Keine Kommentare