9. Testenteam.fh-kl.de/uploads/media/SWE-09-Testen-v03.pdfTesten der kleinsten Software-Einheiten, z. B. Klassen Direkt im Anschluss an die Erstellung Isoliertes Testen der Komponente

9. Testen

Software Engineering

Gliederung Vorlesung

� Einführung

� V-Modell XT

� Analyse und Anforderungsmanagement

� Benutzungsoberflächen

� Architektur

� Entwurf

� Entwurfsmuster

� Persistenz

� Testen

� Konfigurationsmanagement

� Abnahme, Einführung, Wartung und Pflege

Allweyer: Software Engineering

Vorlesung basiert auf:Spillner/Linz: BasiswissenSoftwaretest

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ührung3. Testobjekte4. Zu testende Leistungsmerkmale5. Leistungsmerkmale, die nicht getestet werden6. Teststrategie7. Abnahmekriterien8. Kriterien für Testabbruch und Testfortsetzung9. Testdokumentation10. Testaufgaben11. Testumgebung12. Verantwortlichkeiten/Zuständigkeiten13. Personal, Einarbeitung, Ausbildung14. Zeitplan/Arbeitsplan15. Planungsrisiken und Unvorhergesehenes16. 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: BasiswissenSoftwaretest

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− Auf Basis der dokumentierten Anforderungen, z. B. Use Cases

− Abwicklung kompletter Geschäftsprozesse

� Feldtest● Ü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 + 2pwobei 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



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 WeihnachtsgratifikationenFirmenzugehö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− Atomare Teilbedingung: Bedingung, die keine logischen Operatoren wie AND,

OR, NOT enthält, höchstens Relationssymbole (>, =)

� Bewertung● 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● 2n 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



Testmanagement

� Verwaltung von Fehlern in Fehlerdatenbank

� Aufbau Fehlermeldung:



Fehlerklassifikation



Priorität Fehlerbehebung



Fehlerstatusmodell



Fehlerstatus



Documents

9. Testenteam.fh-kl.de/uploads/media/SWE-09-Testen-v03.pdfTesten der kleinsten Software-Einheiten, z. B. Klassen Direkt im Anschluss an die Erstellung Isoliertes Testen der Komponente