Software Engineering 9. Testen
Gliederung Vorlesung Einführung V-Modell XT Analyse und Anforderungsmanagement Benutzungsoberflächen Architektur Entwurf Entwurfsmuster Persistenz Testen Konfigurationsmanagement Abnahme, Einführung, Wartung und Pflege Vorlesung basiert auf: Spillner/Linz: Basiswissen Softwaretest
Fehlerbegriff Fehler Nichterfüllung einer festgelegten Anforderung Abweichung zwischen Ist-Verhalten und Soll-Verhalten Fehlerwirkung (failure) Fehler wird sichtbar beim Testen oder Anwenden Fehlerursache (Defekt, fault) Entstehung während der Software-Entwicklung Z. B. falsch programmierte Anweisung Ursache für Defekt Fehlerhandlung einer Person (Error) Fehlermaskierung Ein Defekt wird durch einen oder mehrere andere Defekte kompensiert. Fehlerwirkung tritt erst zutage, wenn der andere Defekt behoben ist
Testen vs. Debugging Debugging Lokalisieren und Beheben von Defekten Testen Ziel: Fehlerwirkungen gezielt und systematisch aufdecken. Ausführung eines Testobjekts zur Überprüfung i. A. stichprobenartig Festgelegte Randbedingungen Vergleich zwischen Soll- und Ist-Verhalten
Eine kleine Funktion public void funktion(double a, double b, double c, double d, double e, double f, double g){ for(int i=0;!fertig && i<20; i++){ if(a>b){ //... Anweisungen } else { if (c<d){ if(d==e){ //... Anweisungen } else { //... Anweisungen } } else { if(g>f){ //... Anweisungen } else { //... Anweisungen } } } } }
Testplanung Ressourcen bereitstellen Mitarbeiter, Schulungen Testwerkzeuge Testrahmen (engl. test bed): Benötigte Software, in der die zu testende Software zur Ausführung gebracht wird Teststrategie festlegen Prioritäten festlegen (aufgrund Risiken) Testmethoden festlegen Geforderter Überdeckungsgrad Endekriterien
Gliederung für ein Testkonzept nach IEEE 829 1. Testkonzeptbezeichnung (engl. test plan) 2. Einführung 3. Testobjekte 4. Zu testende Leistungsmerkmale 5. Leistungsmerkmale, die nicht getestet werden 6. Teststrategie 7. Abnahmekriterien 8. Kriterien für Testabbruch und Testfortsetzung 9. Testdokumentation 10. Testaufgaben 11. Testumgebung 12. Verantwortlichkeiten/Zuständigkeiten 13. Personal, Einarbeitung, Ausbildung 14. Zeitplan/Arbeitsplan 15. Planungsrisiken und Unvorhergesehenes 16. Genehmigung/Freigabe
Testspezifikation Spezifikation Testfälle Logische Testfälle Konkrete Testfälle: mit tatsächlichen Eingabewerten Für jeden Testfall: Ausgangssituation (Vorbedingungen) Zu erwartende Ergebnisse / Verhalten Zwei Arten von Testfällen Prüfung der gewünschten Ergebnisse und Reaktionen Inkl. Behandlung von Ausnahmen und Fehlersituationen Prüfung der Reaktion auf ungültige und unerwartete Eingaben und Randbedingungen, für die keine Ausnahmebehandlungen spezifiziert wurden
Testdurchführung Prüfung auf Vollständigkeit Installation des Testobjekts in Testumgebung Überprüfung auf Start- und Ablauffähigkeit Prüfung der Hauptfunktionen Falls bereits zu Beginn grundlegende Probleme auftreten, ist ein detaillierteres Testen zunächst nicht sinnvoll, da erst diese Fehler behoben werden müssen. Weitere Prüfungen
Testprotokollierung Exakte und vollständige Protokollierung der Testdurchführung Nachvollziehbarkeit Auch für nicht direkt beteiligte, z. B. Kunden und Entwickler Der Test muss später mit den gleichen Rahmenbedingungen und Eingabedaten wiederholbar sein Nachweis Verwaltung der relevanten Informationen (Konfigurationsmanagement) Testrahmen Eingabedateien Testprotokoll usw.
Testauswertung Überprüfung der Testergebnisse Prüfen, ob Abweichung tatsächlich eine Fehlerwirkung darstellt (und nicht z. B. durch fehlerhaften Testfall ausgelöst) Entscheidung über Fehlerbehebung Priorisierung anhand Fehlerklasse Erneutes Testen Überprüfen: Fehler behoben? Kein neuer Fehler entstanden? I. d. R. wird eine neue Version getestet, bei der mehrere Fehler behoben sind Entscheidung über Test-Ende Anhand Ende-Kriterien Z. B. 100% aller Anweisungen müssen mindestens einmal ausgeführt worden sein. Fehlerfindungsrate
Fehlerfindungsrate Quelle: Spillner/Linz: Basiswissen Softwaretest
Priorisierung der Tests Man kann nicht alles testen Kriterien für die Priorisierung: Eintrittswahrscheinlichkeit von Fehlern im Betrieb stark genutzte Funktionen werden stärker getestet Mit dem Fehler verbundenes Risiko Wahrnehmung durch Endanwender Was stört ihn besonders? Priorisierung der Anforderungen und Qualitätsmerkmale durch den Kunden Priorisierung aus Entwicklungssicht Von welchen Komponenten sind andere besonders abhängig? Komplexe Komponenten sind fehleranfällig Fehlerwirkungen mit hohem Projektrisiko (hoher Behebungsaufwand)
Teststufen im Softwareprojekt Komponententest Integrationstest Systemtest Abnahmetest
Komponententest Testen der kleinsten Software-Einheiten, z. B. Klassen Direkt im Anschluss an die Erstellung Isoliertes Testen der Komponente Hierdurch wird sichergestellt, dass gefundene Fehler tatsächlich in dieser Komponente liegen Testtreiber Ein Programm, das das Testobjekt aufruft, mit Eingabeparametern versorgt und das Ergebnis entgegennimmt Einsatz von Testwerkzeugen reduziert den Aufwand zur Programmierung der Testtreiber Auch Testen unzulässiger Eingaben (Negativtests) Sinnvolle Reaktionen und Ausnahebehandlungen
Integrationstest Integration von Komponenten zu Teilsystemen Komponenten sollten bereits getestet sein Testen des Zusammenspiels aller Komponenten Fehler in Schnittstellen und im Zusammenspiel der Komponenten finden Schrittweises Zusammenfügen der Komponenten, wobei nach jedem Schritt Integrationstests durchgeführt werden. Ggf. Integration mit existierenden Drittsystemen (z. B. Standardsoftware) Ggf. weitere Diagnoseinstrumente, z. B. Monitore zur Überwachung und Protokollierung der ausgetauschten Daten Typen von Fehlern Eine Komponente übermittelt keine oder syntaktisch falsche Daten Übergebene Daten werden durch die Komponenten unterschiedlich interpretiert Zu späte Übergabe oder zu kurze Zeitintervalle (Timing, Lastprobleme)
Integrationsstrategien Top-down-Integration Test beginnt mit der "obersten" Komponente, die selbst nicht von anderen Komponenten aufgerufen wird. Untergeordnete Komponenten werden zunächst durch Platzhalter ersetzt und später nach und nach gegen die richtigen Komponenten ausgetauscht Wenige verschiedene Testtreiber, aber Platzhalter programmieren Bottom-up-Integration Beginn mit elementaren Komponenten, nach und nach Zusammensetzen zu größeren Komponenten Keine Platzhalter, aber viele Testtreiber Ad-hoc-Integration Integration in der (zufälligen) Reihenfolge der Fertigstellung Zeitgewinn, aber sowohl Platzhalter als auch Treiber benötigt Big bang-integration Vermeiden, da großer Testaufwand am Ende, Fehler treten geballt auf und sind schwer zu lokalisieren.
Systemtest Test des vollständig integrierten Gesamtsystems Insbesondere aus Kunden- und Anwenderperspektive Testumgebung endspricht möglichst der späteren Produktivumgebung Möglichst nicht direkt in der Produktivumgebung Fehler wirken sich auf Produktivsysteme des Kunden aus Keine Kontrolle über Parameter und Konfiguration Statt Testtreibern und Platzhaltern: tatsächliche Systeme und Komponenten Testen funktionaler Anforderungen Feldtest Auf Basis der dokumentierten Anforderungen, z. B. Use Cases Abwicklung kompletter Geschäftsprozesse Überprüfung sämtlicher unterschiedlicher Produktivumgebungen oft nicht möglich Beta-Tests durch Kunden
Systemtest: Nicht-funktionale Anforderungen Lasttest Performanztest Volumen-/Massentest Stresstest Was passiert bei Überlastung? Test der Sicherheit Z. B. gegen unberechtigten Systemzugang Test der Stabilität/Zuverlässigkeit Im Dauerbetrieb Test auf Robustheit Gegenüber Fehlbedienung, Hardwareausfall, Wiederanlauf, Test auf Kompabilität/Datenkonversion Test unterschiedlicher Konfigurationen Z. B. Sprachen, Betriebssysteme Test auf Benutzungfreundlichkeit Prüfung der Dokumentation Prüfung auf Änderbarkeit/Wartbarkeit
Abnahmetest Test auf vertragliche Akzeptanz Grundlage: Abnahmekriterien des Vertrags
Regressionstest Nach Fehlerbehebung, Wartung, Weiterentwicklung muss die Software erneut getestet werden Nachweis, dass keine neuen Fehler eingebaut wurden Notwendiger Umfang? Fehlernachtest: Wiederholung aller Tests, die die Fehlerwirkung erzeugt hatten. Test geänderter Funktionalität Test neuer Funktionalität Das komplette System (vollständiger Regressionstest) Eigentlich wäre ein vollständiger Regressionstest erforderlich In der Praxis wägt man ab, welche Tests sinnvoll wiederholt werden können und sollen Automatisierte Tests lassen sich leichter wiederholen
Statischer Test Reviews Statische Analyse Compiler, Analysatoren Syntaxverletzungen, Inkonsistenzen, Abweichungen v. Standard, Einhaltung von Konventionen und Standards Datenflussanomalien Untersuchung der Daten auf Pfaden durch Programmcode Z. B. Eine Variable erhält zweimal einen Wert zugewiesen, ohne dass dieser inzwischen gelesen wird. Kontrollflussanomalien Z. B. Nicht erreichbare Anweisungen Metriken Z. B. Zyklomatische Zahl zur Bestimmung der Komplexität von Kontrollflussgraphen, sollte kleiner als 10 sein v(g) = e n + 2p wobei e: Zahl der Kanten, n: Zahl der Knoten, p: Zahl der verbundenen Komponenten (einzelne Kontrollflussgraphen)
Dynamischer Test PoC: Point of Control, PoO: Point of Observation Quelle: Spillner/Linz: Basiswissen Softwaretest
Dynamische Testverfahren Black-box-Verfahren Programmtext und innerer Aufbau des Testobjekts nicht berücksichtigt Nur äußeres Verhalten des Testobjekts untersucht Insbesondere Systemtests i.d.r. nur als Black-box-Test durchgeführt White-box-Verfahren Verwendung des Programmtexts Analyse des inneren Ablaufs (Point of Observation im Testobjekt) Evtl. Eingriffe in das Testobjekt Erstellung von Testfällen aufgrund innerer Programmstruktur (strukturelle Testverfahren) Eignet sich insbesondere für Komponententests
Black-box-Verfahren: Äquivalenzklassenbildung Äquivalenzklasse Die Menge aller möglichen Eingabewerte wird in Äquivalenzklassen unterteilt Für Eingabewerte, die sich in einer Äquivalenzklasse befinden, müsste sich das Testobjekt gleich verhalten Es müssen daher nur einige Repräsentanten aus jeder Äquivalenzklasse getestet werden Auch Äquivalenzklassen für ungültige Eingaben Interessant: Prüfung der Grenzen von Äquivalenzklassen Weitere Black-box-Verfahren Zustandsbezogene Tests Berücksichtigung der Historie Z. B. Erreichen aller möglichen Zustände durch Testfälle Zufallstest Ursache-Wirkungs-Graph-Analyse Smoke-Test Versuch, das System zum Absturz zu bringen
Beispiel für Äquivalenzklassenbildung Programm zur Berechnung von Weihnachtsgratifikationen Firmenzugehörigkeit (Jahre) Gratifikation x <= 3 0% 3 < x <= 5 50% 5 < x <= 8 75% x > 8 100%
White-box-Verfahren Berücksichtigung des Programmtexts Alle Codeteile sollen mindestens einmal zur Ausführung gebracht werden Verfahren zum Testfallentwurf: Anweisungsüberdeckung Zweigüberdeckung Test der Bedingungen Einfache Bedingungsüberdeckung Mehrfachbedingungsüberdeckung Minimale Mehrfachbedingungsüberdeckung Pfadüberdeckung
Anweisungsüberdeckung Durch die spezifizierten Testfälle sind x% aller Anweisungen des Programms zur Ausführung zu bringen Am besten 100% Gelegentlich gibt es Anweisungen zur Ausnahmebehandlung, die nur schwer erreichbar sind. Anweisungsüberdeckung = Zahl durchlaufener Anweisungen / Gesamtzahl Anweisungen Bewertung Nicht erreichbarer Code wird gefunden Leere "else"-teile werden nicht erkannt Wenn nur im if-teil Anweisungen vorkommen, im else-teil Anweisungen fehlen, werden diese nicht gefunden, da der else-teil mangels enthaltener Anweisung gar nicht durchlaufen wird
Zweigüberdeckung Es sollen möglichst alle Zweige im Kontrollflussgraphen erreicht werden Bei Verzweigungen (if, case) soll jeder ausgehende Zweig mindestens einmal durchlaufen werden. Bei einer Schleife soll ein Pfad ohne Rücksprung sowie ein Rücksprung zum Anfang durchlaufen werden Zweigüberdeckung = Anzahl durchlaufener Zweige / Gesamtzahl Zweige Bewertung Es werden Fehler gefunden, die nur mit Anweisungsüberdeckung nicht gefunden werden Bei objektorientierten Systemen sind die Methoden meist wenig komplex, die Überdeckungen lassen sich leicht erreichen. Die Komplexität steckt in den Beziehungen zwischen Klassen, die bei den bisherigen Tests nicht berücksichtigt wird.
Test der Bedingungen Einfache Bedingungsüberdeckung Jede atomare Teilbedingung muss im Test sowohl den Wert wahr als auch falsch angenommen haben Bewertung Atomare Teilbedingung: Bedingung, die keine logischen Operatoren wie AND, OR, NOT enthält, höchstens Relationssymbole (>, =) Schwächer als Anweisungs- oder Zweigüberdeckung, da keine unterschiedlichen Wahrheitswerte der Gesamtbedingung verlangt sind
Mehrfachbedingungsüberdeckung Möglichst alle Kombinationen der Wahrheitswerte der atomaren Teilbedingungen Erfüllt auch die Kriterien der Anweisungs- und Zweigüberdeckung Aufwändig 2 n Kombinationen bei n atomaren Bedingungen Es lassen sich nicht alle Kombinationen realisieren Bedingungen sind nicht immer unabhängig
Minimale Mehrfachbedingungsüberdeckung Unterschied zur Mehrfachbedingungsüberdeckung: Es müssen nur die Kombinationen betrachtet werden, bei denen die Änderung des Wertes einer atomaren Bedingung den Wert der zusammengesetzten Bedingung verändern kann Weniger Aufwändig Nur bis zu 2n Kombinationen bei n atomaren Bedingungen Evtl. schwierig, die Eingabedaten so zu wählen, dass eine bestimmte Teilbedingung den gewünschten Wert annimmt
Pfadüberdeckung Jeder mögliche Pfad muss durchlaufen werden D. h. nicht nur jeder mögliche Zweig, sondern auch jede Kombination von Zweigen Jeder Schleifendurchlauf ergibt mindestens einen neuen Pfad In der Praxis lässt sich keine 100%-Pfadüberdeckung erreichen. Meist legt man eine bestimmte Schleifendurchlaufzahl fest (z. B. 2), die getestet werden soll.
Beispiel für Pfadüberdeckung Komplette Zweigüberdeckung: a, b, c, j, k, l, n a, d, e, f, i, j, m, n a, d, g, h, i, j, m, n Nicht durchlaufene Pfade: a, b, c, j, m, n a, d, e, f, i, j, k, l, n a, d, g, h, i, j, k, l, n Quelle: Spillner/Linz: Basiswissen Softwaretest
Testmanagement Verwaltung von Fehlern in Fehlerdatenbank Aufbau Fehlermeldung: Quelle: Spillner/Linz: Basiswissen Softwaretest
Fehlerklassifikation Quelle: Spillner/Linz: Basiswissen Softwaretest
Priorität Fehlerbehebung Quelle: Spillner/Linz: Basiswissen Softwaretest
Fehlerstatusmodell Quelle: Spillner/Linz: Basiswissen Softwaretest
Fehlerstatus Quelle: Spillner/Linz: Basiswissen Softwaretest