Übersicht Inhalt: Testkonzept/-plan Testarten, -stufen und -phasen Testmethoden, speziell für white box testing: Kontrollflussbasiert (neu) Datenflussbasiert (neu) Testszenarien und Testfälle Unittest Integrationstest Fehlermanagement Datei: Vorlesung.ppt Seite 1
Testkonzept/-plan Im Testkonzept (häufig auch bezeichnet als Testplan) werden zuerst die geplanten Testarten (auch bezeichnet als Teststufen bzw. Testphasen) festgelegt (s. nächste Seite). Dabei wird für jede Testart folgendes festgelegt: Ziel Zuständigkeit (für Koordination, Durchführung und Abnahme) Zeitraum der Durchführung Testmethode Aufwandsabschätzung Testumgebung (incl. Tool): Treiber für benötigte Testdaten Treiber für erforderliche Aufrufmodule Simulation der aufgerufenen Module Seite 2
Testarten/-phasen/-stufen Unittest Testart Technischer Integrationstest Anwendungstest Integrationstest Rollentest Performancetest Regressionstest Recoverytest Inbetriebnahmetest Systemtest (Systemtest), Volumentest Upgradetest Backuptest häufig bezeichnet als Komponententest, Modultest, Produkttest delivery acceptance test application integration test business integration test Installationskontrolltest, operations readyness test Ziel Sicherstellung der Funktionsfähigkeit von Schnittstellen und Systemfunktionen Sicherstellen, daß die entwickelte Komponente technisch ablauffähig ist Sicherstellung der Funktionsfähigkeit des Gesamtsystems Sicherstellung der Durchgängigkeit von Prozessen unter Einbindung der angrenzenden Systeme, d.h. Sicherstellung der fachlichen Integration Sicherstellung der Funktionsfähigkeit der mit den Rollen verbundenen Berechtigungsprüfungen Frühzeitiges Feststellen von Performance-Problemen auf Basis von Echtdaten Sicherstellung des Produktivbetriebs bei Einspielen von neuen Releases Sicherstellung des korrekten Neuaufsetzens nach einem Systemstillstand Sicherstellung der Funktionsfähigkeit der wichtigsten Schnittstellenanbindungen Sicherstellen der IT-technischen Integration, d.h. u.a. dass die Anwendung weiterhin den Betriebsanforderungen entspricht. Seite 3
Testmethoden Black Box Testing (funktionsorientiertes ) Spezifikation des Testobjekts als Ausgangspunkt der Testdatenermittlung Testdaten werden in Klassen eingeteilt, bei jedem Repräsentant einer Klasse verhält sich das Testobjekt gleich Qualität der Testdaten hängt ab von der Aussagekraft der Spezifikation Es kann nicht ermittelt werden, ob das Programm mehr tut als es soll (Computerkriminalität) White Box Testing (strukturorientiertes ) Programmtext als Ausgangspunkt der Testdatenermittlung möglichst viele Programmabläufe werden ausgeführt unterschiedliche Überdeckungen werden angestrebt (C0, C1, ) Programme können getestet werden, für die keine Spezifikation vorliegt vergessene Teile der Spezifikation können nicht gefunden werden es ist nicht erkennbar, ob die getesteten Anweisungen im Betrieb überhaupt ausgeführt werden Seite 4
Kontrollflussbasierter Test Verfahren zum White Box Testing C0-Überdeckung, Anweisungsüberdeckung, statement coverage (alle Knoten) C1-Überdeckung, Zweigüberdeckung, branch coverage (alle Zweige) CGI, Grenze-Inneres Test C -Überdeckung, Pfadüberdeckung, path coverage (alle Pfade) Test der Bedingungen C2-Überdeckung, Bedingungsüberdeckung (alle Bedingungen, auch Teile davon) Mehrfachbedingungsüberdeckung (alle Kombinationen der Teilbedingungen) Datenflussbasierter Test Überdeckungsgrad bzgl. der Datenverwendung (Def/Uses-Verfahren): (zustandsverändernde) Wertzuweisung: z.b. r=0 (zustandserhaltende) Benutzung in Ausdrücken: z.b. f(r) (zustandserhaltende) Benutzung in Entscheidungen: z.b. r>0 Seite 5
White Box Testing: C0-Überdeckung Kontrollfußgraph vom ggt (Bsp.:ggT(4,8)=4, ggt(5,8)=1, ggt(15,35)=5) 1 2-3 4-6 7 8 9-11 12 1. public int ggt(int m, int n) { 2. int r; 3. if (n > m) { 4. r = m; 5. m = n; 6. n = r } 7. r = m % n; 8. while (r!= 0) { 9. m = n; 10. n = r; 11. r = m % n; } 12. return n; 13. } Ein Testfall für die 100%ige C0-Überdeckung: 1,2-3,4-6,7, 8,9-11,8,12,13 Der Pfad 2-3,7 wird nicht getestet, weil in diesem Pfad keine Anweisung enthalten ist 13 Seite 6
White Box Testing: C0-Überdeckung Beispiel für nicht gefundenen Fehler bei der C0-Überdeckung: Mit den Testdaten x=5 und y=0 wird zwar die C0- Überdeckung erfüllt, jedoch wird der Fehler im falschen Programm nicht gefunden, denn die Sollwerte x=25 und y=30 werden in beiden Fällen erreicht. Seite 7
White Box Testing: C1-Überdeckung 1 2-3 4-6 1 2-3 4-6 Zwei Testfälle für die 100%ige C1-Überdeckung: 1,2-3,4-6,7, 8,9-11,8,12,13 1,2-3,7,8,12,13 neu 7 7 8 9-11 12 13 8 9-11 12 13 Jedoch: Schleifen werden nicht ausreichend getestet. Komplexe Bedingungen werden nicht getestet. Kombinationen von Zweigen werden nicht getestet. Seite 8
White Box Testing: C1-Überdeckung Beispiel für gefundenen Fehler bei der C1-Überdeckung: Mit den Testdaten x=5 und y=0 (Ergebnis: x=25, y=30) wird der eine Test durchgeführt, mit x=-1 und y=0 (Ergebnis: x=-1, y4) der zweite Test. Der Fehler wird im Gegensatz zur C0-Überdeckung gefunden. Seite 9
White Box Testing: CGI-Überdeckung Die CGI-Überdeckung (Grenze-Inneres) bezieht sich nur auf Schleifenanweisungen und fordert, dass jede Schleife in mindestens einem Testfall gar nicht (gilt nur bei abweisenden Schleifen, while, for nur wenn Abbruchbedingung bei erstmaliger Auswertung wahr) genau einmal und mehr als einmal ausgeführt wird. 1 2-3 4-6 7 3 Testfälle für die CGI-Überdeckung: 8 1,2-3,7,8,12,13 1,2-3,4-6,7, 8,9-11,8,12,13 1,2-3,4-6,7, 8,9-11,8,9-11,8,12,13 9-11 12 13 Seite 10
White Box Testing: Bedingungsüberdeckung Die C2-Überdeckung (Bedingungsüberdeckung) berücksichtigt komplexe/zusammengesetzte Bedingungen, indem sie fordert, alle Teilbedingungen zu variieren. Jedoch ist nicht gefordert, dass unterschiedliche Wahrheitswerte bei der Auswertung der gesamten Bedingung berücksichtigt werden. Somit ist die Anweisungsbzw. Zweigüberdeckung stärker, da manche Zweige bei der C2-Überdeckung nicht getestet werden. Testfall1: A=2, B=1, C=4 Testfall2: A=1, B=0, C=1 Die Testfälle überdecken zwar alle Variationen der Teilbedingungen, jedoch wird der Pfad c nicht getestet. Seite 11
White Box Testing: Bedingungsüberdeckung Bei der Testfallermittlung sollte man sowohl die C2-Überdeckung (Bedingungsüberdeckung) als auch die Zweigüberdeckung berücksichtigen (s. auch Beispiel vorige Folie): Testfall1: A=2, B=0, C=4 Pfad a-c-e Testfall2: A=1, B=1, C=1 Pfad a-b-d Mit diesen Testfällen werden zwar alle Zweige überdeckt, jedoch nicht alle Zweigkombinationen. Um das zu zeigen, benötigt man eine äquivalente Umformung des Kontrollflussgraphen: Seite 12
Testfall1: A=2, B=0, C=4 White Box Testing: Bedingungsüberdeckung A>1 true B=0 true Testfall2: A=1, B=1, C=1 false false C:=C/A Zwei Zweige fehlen: Lösung: false A=2 true Mehrfachbedingungsüberdeckung (C3-Ü.) Die C3-Überdeckung ist dann erfüllt, wenn jede Kombination der Wahrheitswerte aller Teilbedingungen in Testfällen ausgeführt wird. C>1 true C:=C+1 false Seite 13
White Box Testing Datenflussbasiertes (Def/Uses-Verfahren) Getestet werden Interaktion zwischen Anweisungen, die einer Variablen einen Wert zuweisen (definieren), und Anweisungen, die diesen Variablenwert benutzen (referenzieren): Wertzuweisung (Definition, definitional use, def) Berechnungsreferenz (Benutzung in Ausdrücken, computational use, c-use) Entscheidungsreferenz (Benutzung in Bedingungen, predicative use, p-use) verschiedene Test-/Überdeckungskriterien (Metriken): Alle Definitionen: Das Resultat einer Zuweisung (Definition) wird wenigstens einmal benutzt (c-use oder p-use) Alle DR-Interaktionen: jedes Paar (def/ref) auf irgendeinem Weg ausführen def(r) Alle Referenzen: p-uses und c-uses. r = m % n r = op1(m,n) while (r!= 0) if (r == 0) c-use(m,n) p-use(r) Seite 14
Verfahren zum White Box Testing Kontrollflussgraph mit Datenflussannotation: 1 def(m,n) Bsp. für DR-Interaktionen: (1, m, 4, r, 6): m wird in 1 definiert, in 4 referenziert, r wird in 4 definiert und in 6 referenziert; damit hängt 6 von 1 ab. (1, m, 7, r, 10):.. 1. public int ggt (int m, int n) { 2. int r; 3. if (n > m) { 4. r = m; 5. m = n; 6. n = r } 7. r = m % n; 8. while (r!= 0) { 2 3 4 5 6 7 8 def(r) p-use(m,n) def(r), c-use(m) def(m), c-use(n) def(n), c-use(r) def(r), c-use(m,n) p-use(r) Teste die Wegstücke: (1, 2, 3, 4, 5, 6) und (1, 2, 3, 7, 8, 9, 10) 9. m = n; 10. n = r; 11. r = m % n; } 12. return n; 9 10 11 def(m), c-use(n) def(n), c-use(r) def(r), c-use(m,n) 13. } 12 c-use(n) Seite 15
Verfahren zum White Box Testing Testverfahren C0, (statement coverage) Anweisungsüberdeckung C1, (branch coverage) Zweigüberdeckung C2, Bedingungsüberdeckung Mehrfach-Bedingungsüberdeckung CGI, Grenze-Inneres Test C, (path coverage) Pfadüberdeckung Datenflusstest Leistungsfähigkeit Niedrig Entdeckt knapp 1/5 der Fehler Entdeckt ca. 1/3 aller Fehler und 80% der Kontrollflussfehler Niedrig Hoch Mittel Sehr hoch Entdeckt ca. 2/3 aller Fehler Mittel bis hoch All c-uses deckt 1/2 aller Fehler auf All p-uses deckt 1/3 aller Fehler auf All defs deckt 1/4 aller Fehler auf Bewertung Entdeckt dead code Mit and. Verfahren kombinieren DAS minimale Testkriterium Umfasst i.allg. nicht die C0- und C1- Überdeckung, da Bedingungen evtl. in Anweisungen neu berechnet werden Umfasst Zweigüberdeckung Aufwand wächst stark Zielt auf komplexe Schleifen Nur als Ergänzung In den meisten Fällen nicht praktikabel Zielt auf Variablen-Verwendung C-uses findet viele Berechnungsfehler Seite 16
Testszenarien und Testfälle Für jede der geplanten Testarten werden die Testszenarien (o. a. Testumfänge) in Form einer Liste von Testfällen festgelegt. Für jeden Testfall gibt es dann eine Testanweisung und ein Testprotokoll, die häufig in einem(!) Formular zusammengefasst sind. Die Beschreibung eines Testfalls beinhaltet somit folgendes: Beschreibung des Testfalls und der dazugehörigen Testschritte incl. Testbedingungen und Testdaten Name des Erstellers der Testanweisung Name des Freigebenden der Testanweisung Name des Testers Name des Abnehmenden Die zu testende Eigenschaft (Korrektheit, Bedienoberfläche, Performance, ) Erwartetes Ergebnis Tatsächliches Ergebnis (diese Information liegt natürlich erst nach der Testdurchführung vor) Seite 17
Unittest typgerechte Verwendung aller Datenobjekte (ungewollte Konvertierungen) Objektverwendungsnachweise (Cross reference list, Aufrufhierarchie/-graph) Datenflussanalyse von Programmobjekten (Variablen, Konstanten): Objekte werden vor ihrer Definition verwendet Objekte werden mehrfach überschrieben, ohne vorher verwendet worden zu sein Objekte werden definiert, ohne danach verwendet zu werden nur-lesbare Objekte werden überschrieben: z.b. Prüfung durch den ANSI-C-Compiler bei Verwendung des Schlüsselworts CONST: char *strcpy (char *ziel, const char *quelle); (der Speicherbereich quelle darf von der Funktion nicht verändert werden). Statisch unerreichbare Programmsequenzen (z.b. fehlendes GOTO bei vorh. Sprungmarken) Hinweise auf krasse Programmierfehler (z.b. nicht terminierende Schleife) Prüfung von Programmierkonventionen und Qualitätsstandards (z.b. Namensgebung, Schachtelungstiefe, Komplexität) Seite 18
Unittest (Komplexität, Überdeckung)... Komplexität: metric of McCabe: Cyclomatic Number is the maximum number of independent paths in a flowgraph 1 IF a>b v(g) = e - n + 2p 2 3 4 THEN IF b>c THEN p(a,b) ELSE p(b,c); v(g) - Cyclomatic Number of the flowgraph G e - number of edges in G n - number of nodes in G p - number of connected components (if you have subprograms, p=1 in a single program) v(g) = 8-7 + 2*1 = 3 5 Print(a,b,c); Überdeckung:... Statement coverage: 1-2-3-5 und 1-2-4-5 Branch coverage: 1-5 (additional) Seite 19
Integrationstest Syntaxprüfung der Schnittstellen (z.b. falsche Anzahl von Parametern oder nicht übereinstimmender Parametertyp), z.b. Prüfung der Argumente/aktuellen Parameter bei einem Funktionsaufruf unter Verwendung des Funktions-Prototypen zur Deklaration der Funktionen durch den ANSI-C-Compiler: float hoch (float zahl, int potenz) Kopplungskategorisierung nach Myers, sechs Abstufungen für die interne Festigkeit eines Moduls (Cohesion), fünf Abstufungen für die Bindung zu anderen Moduln (Coupling) Anzeige verdeckter Abhängigkeiten, Beispiel: Zwei Module verwenden (importieren) eine externe Variable, die von einem dritten Modul bereitgestellt wird, d.h. die Kopplung zwischen den beiden benutzenden Moduln ist nicht unmittelbar ersichtlich Intermodulare Datenflussanalyse, Beispiel: Ein Parameter erhält vor dem Aufruf der Schnittstelle einen Wert und wird in der aufgerufenen Funktion sofort überschrieben, ohne vorher gelesen zu werden Ausschöpfen der Parameterbereiche: Prüfung der Ausnahmebehandlungen und Grenzfälle (sind häufig in den Simulationen vernachlässigt worden), des Modulverhaltens bei Systemfehlern, der über Modulgrenzen hinweg realisierten Fehlerbehandlungen und der globalen Variablen Überprüfen der Aufrufreihenfolge: systemweite Überprüfung auf Einhaltung vorgeschriebener Abläufe und Protokollierung der Abläufe einzelner Operationen Funktionalitätsprüfung (Zusammenwirken von Teilfunktionen) stat. dyn. Seite 20
Fehlermanagement beim Fehlerstatus Neu Offen Abgewiesen Analyse Beobachtung Korrektur Test Erledigt Flop Gesetzt durch Tester Testmanager (TM) Testmanager Entwickler Entwickler Projektmanager Entwickler Tester Tester Bedeutung Neue Fehlermeldung (s. nä. Folie) wurde erfasst. Der Tester hat eine aus seiner Sicht sinnvolle Beschreibung und Klassifizierung eingetragen. TM sichtet die Meldungen, bereitet sie für eine einheitliche Bewertung auf, löscht ggfs. Dubletten und weist die Meldung einem Entwickler zu. Meldung wird als unberechtigt abgewiesen (kein Defekt im Testobjekt, Änderungswunsch, der nicht berücksichtigt wird). E. dokumentiert das Ergebnis der Problemanalyse (Ursache, Lösungsmöglichkeiten, geschätzter Korrekturaufwand) in Form von Kommentaren. Das Problem kann nicht nachvollzogen/ausgeschlossen werden. Meldung bleibt unerledigt, bis weitere Informationen/Erkenntnisse vorliegen. Projektmanager entscheidet aufgrund der Analyse, dass die Korrektur erfolgen soll. Der zuständige Entwickler dokumentiert die Art der Korrektur. Der zuständige Entwickler behebt das Problem. Die Softwareversion, in der die Korrektur verfügbar ist, wird angegeben. Tester wiederholt im nächstmöglichen Testzyklus den fehleraufdeckenden Test und setzt bei erfolgreicher Fehlerbeseitigung den Endzustand. Ergibt der Fehlernachtest, dass die Fehlerbeseitigung erfolglos oder ungenügend war, ist eine erneute Analyse notwendig. Seite 21
Fehlermeldung: Identifikation und Klassifizierung Attribut Nummer Testobjekt Plattform Entdecker Entwickler Erfassung Status (s. vo. Folie) Klasse Priorität Anforderung Fehlerquelle Bedeutung laufende, eindeutige Meldungsnummer Identifikation der genauen Version des Testobjekts Identifikation der HW-/SW-Plattform bzw. der Testumgebung, in der das Problem auftritt Identifikation des Testers (ggf. mit Teststufe), der das Problem meldet Name des für das Testobjekt verantwortlichen Entwicklers oder Teams Datum, ggf. Uhrzeit, an dem das Problem beobachtet wurde Bearbeitungsfortschritt der Meldung; möglichst mit Kommentar und Datum Klassifizierung der Schwere des Problems Klassifizierung der Dringlichkeit einer Korrektur Verweis auf die (Kunden-)Anforderung, die wegen der Fehlerwirkung nicht erfüllt oder verletzt ist Soweit feststellbar, die Projektphase, in der die Fehlhandlung begangen wurde (Analyse, Design, Programmierung); nützlich zur Planung prozessverbessernder Maßnahmen Seite 22