Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03233.jsonl.gz/2163

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.