Analytische QS-Methode

Konstruktiver Prozess: Produkt wird nicht “zerstört” - Fehler finden spart Fehlerkosten.

Ausführen von Programm mit der Absicht:

Nicht mit der Absicht:

Überprüfung vom Laufzeitverhalten von Systemteilen:

Umsetzung von Qualität benötigt:

– Testfälle vor der Implementierung erstellen für automatischen Retest – Früher Review von wichtigen Akzeptanztestfällen

– Spezifikation vor detaillierten Entwurf testen

Abweichung von Spezifikation

Abweichung von Nutzer-Anforderungen

Test gegen Spezifikation (Pflichtenheft, ...)

Nach jeder Phase durchführen

“Bauen wir das Produkt richtig?”

Test gegen Nutzeranforderungen

“Bauen wir das richtige Produkt?”

Lange Zyklen

Schwierige Fehlersuche

Kurze Zyklen

selbstorganisierende Teams

Schreiben von Beschreibung vor Umsetzung des Source-Codes

1. Think

   – Auswahl der Anforderungen die implementiert werden sollen – Testfall-Spezifikation

2. Red

   Implementierung und Ausführung der Testfälle

   – Alle Tests müssen fehlschlagen

3. Green

   Implementierung der Komponenten und Klassen und Ausführung der Testfälle

   – erfolgreich → weiter bei Schritt 4, Refactor – schlägt fehlt → weiter bei Schritt 3, Green

4. Refactor

   Optimierung der Implementierung ohne Änderung der Funktionalität, Ausführung der Testfälle.

   – Testfälle dürfen nicht fehlschlagen. – Auswahl der nächsten Anforderung (weiter zu Schritt 1)

= ein System, das bei Änderungen (neue Version im Versionsverwaltungssystem) automatisch die zusammenhängenden Tools (CI Pipeline) nutzt um eine Routine automatisch durchzuführen:

In maven ohne pipeline zB mit ”Cruise Control“, ”Apache Continuum“ und Bug-Tracking tools.

– repetitive manuelle Tätigkeiten reduzieren – Die Effizienz des Testens zu steigern: Hohe Anzahl an Tests in angemessener Zeit ausführen – Tests durchführen, die man nicht manuell durchführen kann (z.B. Last-Tests) – Automatisch Reports der Testergebnisse generieren

Ist eingebettet in Projektplan

1. Planung & Steuerung (Vorbereitung von “Test-Masterplan”)

   von Teststufen: zB Modultest, Integrationstest, Akzeptanztest

   von Testmethoden: Test von funktionalen Anforderungen, nicht-funktionalen Anforderungen

2. Analyse / Design (Spezifikation)

3. Realisierung und Durchführung (Testläufe)

4. Auswertung und Bericht (Testergebnisse)

5. Abschluss (zB Archivierung)

Tests bestehen aus einer Menge Testfälle ( = Testsuite )

Testfall bestehen aus einer Menge (V, E, A, R)

• NF Normalfall soll bei korrekter Implementierung funktionieren

• SF Spezialfall Grenze zwischen Normalfall und Fehlerfall

• FF Fehlerfall soll bei korrekter Implementierung Fehlermeldung werfen

Auswahl von Testfällen:

Wenn Fehler gefunden wird

Tests die keine Fehler aufdecken bieten Information über Produktqualität durch systematische Testüberdeckung

Value-Based-Testing beruht darauf dass nicht alle Testfälle bzw. alle Fehler gleich viel Wert sind.

Requirements-Based Welche Anforderungen bringen den meisten Mehwert für Kunden?

Risk-Based Welche Risiken gefährden den Nutzen am meisten? (zB dependencies)

Test Case Selection Testfälle finden die all diese Risiken und Nutzen abdecken

Zerlegung von Datenmenge (Input oder Output) in Untermengen (Klassen) basierend auf erwartetes Verhalten

Jede Klasse muss 1x getestet werden

1. Zu testende Funktion bestimmen

2. Eingabe-Vektoren (Faktoren) finden (A, B, C, ...):

   explizit: Parameter

   implizit: globale Variablen, Systemzustand, Datenbankzustand, ...

3. Für jeden Faktor seine gültigen, ungültigen Äquivalenzklassen finden und aus jeder Klasse einen Wert wählen

   A → A1, A2, ...

   B → B1, B2, ...

4. Eine Kombination wählen

   die Wahl bestimmt die Intensität

Erweiterung der Äquivalenzklassenzerlegung für bessere Überdeckung

Grenzwerte für jede Klassengrenze und dazu je ein Testfall

Ist eine Vertiefung der Äquivalenzklassenzerlegung, bei der gezielt die Ränder (= Grenzwerte) von den einzelnen Klassen überprüft werden, da dort am häufigsten Fehler (zB falscher Vergleichsoperator, oder Index one-off Fehler) auftreten.