2008. Cambridge University Press.
Testlevels entsprechen Developement Aktivitäten:
- Acceptance Test – Requirements
- System Test – Architectur
- Integration Test – SubsystemDesign
- Module Test – detail design
- Unit Test – Implementierung
- Regression Test – zusätzlich
Grundsatz: Testen kann nur Fehler zeigen, nicht Ihre Abwesenheit
Begriffsbestimmung
- Software Validierung: Nach der Softwareentwicklung überprüfen, ob sie der beabsichtigten Nutzung dient
- SoftwareVerifikation: entprechen die Resultate einer Entwicklungsphase den Anforderungen der vorherigen Phasen?
- Software Fault: ein statische Defekt
- Software Error: ein inkorrektur interner Zustand als Manifestation eine Fault
- Software Failure: external inkorrektes Verhalten
- Testing: Software Evalution durch Beobachten ihres Verhaltens
- Test Failure: Execution die ein Failure erzeugt
- Debugging: der Prozess aus einer failure den fault zu finden
- für failure braucht es drei Bedinungen
- Reachability: der Fault muss erreicht werden
- Infection: nachdem das Statement ausgeführt wird, muss der State falsch werden (auch bei fehlendem Code, dann ist PC per Definition falsch)
- propagation: der infizierte Zustand muss sich bis zum Output verbreiten
- test case values: Inputwerte für eine Ausführung software under test
- Test Requirement: spezifisches Element, das ein Test abdecken muss (meist Menge)
- Coverage Criterion Regelmenge, die TestRequirements definieren
- Subsumption: Criterion C1 subsumes C2, wenn TestSet S satisfies C1 dann auch C2
Es gibt 4 Klassen von Coverage Criterien: Graph, Logic, InputSpace und Syntax
Graph Coverage
- simple Path: ausser erstem und letzten sind alle Knoten verschieden
- prime path: simple Path der in keinem anderen simplen Path echt enthalten ist
- verschiedene Kriterien:
- TR enthält alle Knoten
- TR enthält all Kanten (d.h. All Pfade von Länge 0 und 1, um alle Knoten zu subsume)
- TR enthält alleKantenPaare (alle Pfade der Länge 0, 1, 2)
- TR enthält jeden prime Path
- spezielle Berücksichtigung von nicht erreichbaren Pfaden und Zyklen
- Datenflow Kriterien: def-use Pairs: Pfade von Definition (assignment etc.) zu Benutzung eines Wertes (ohne weitere def drin)
- zu benutzende Graphen
- Control Flow Graph
- Data Flow Graph
- design elements: call graph (Prozeduren, Methoden, Module), Inheritance und Polymorphismus, Dataflow auf Designelementen
- Spezifikation: Sequencing Constraints, ableiten des Graphs eines endlichen Automaten (states auf Aequivalenzklassen von Variabelnwerten reduzieren!)
- für use cases
- Graphen als (regular expressions) von Pfadausdrücken (um sie leichter bearbeiten zu können um Testfälle abzuleiten):
- AB Konkatinierung der Pfade A und B
- A + B: Verzweigung in zwei Pfade A und B
- A* 0 bis n Wiederholungen des Pfades A (Loop Konstrukt)
Logic Coverage
arbeiten auf Mengen von Prädikaten und ihren Klauseln
- jedes Prädikat muss einmal wahr und einmal falsch werden
- jede Klausel muss einmal wahr und einmal falsch werden
- jede aktive Klausel (d.h. Die in der aktuellen Konstellation einen Einfluss auf das Prädikat hat)
- inaktive Klauseln verändern Prädikatwert nicht (4 Fälle Prädikat 1/0, Klausel 1/0)
- die richtigen Inputwerte zu finden ist nicht einfach, erstens muss das Prädikat erreicht werden, zweitens mit passender Variabelnbelegung!
Input Space Partitioning
- IDM = InputDomainModel teil den Inputraum in Aequivalenzklassen auf
- Interface base Partioning: jede InputVariable einzeln partitionieren und dann kartesische Produkt
- functionality based approach: Inputraum von der Funktionalität her Partitionieren
- oder mehrere IDMs kombinieren
- testvalues
- Werte aus verschiedenen Partitionen kombinieren
- innere Werte und Grenzwerte testen
Syntax-Based Testing
- BNF Coverage Criteria
- jedes Terminal
- jede Produktion
- alle Ableitungen
- MutationsTesting: gültige Produktionen werden mit einem Operator mutiert (entweder gültige oder ungültig in der Grammatik)
- ein Test t killt einen Mutant m einer Ableitung D, wenn der Output von t auf D und m unterschiedlich ist
- Mutation Coverage: für jeden Mutanten m enthält TR genau ein Requirement um m zu killen
- MutationOperatorCoverage: für jeden MuationsOperator enthält TR ein Requirement um einen mutierten String abzuleiten
- MutationProduction Coverage ...
- ProgrammSuiten für Compiler und andere Programme mit Grammatik beschriebenem Input
- Programm Mutationen:
- TR soll Kriterien enthalten, die mutierte Programme entdecken
- Mutationsoperatoren: Zahlen mit abs, negAbs usw. Verändern, Prädikate oder Klauseln negieren (oder sonstwie logisch veränden) AssignmentOperatoren ersetzen += durch *= usw.)
- Integration Mutation: Parameter in jedem Call mutieren oder vertauschen
Practiacal Considerations
- Regression Testing
- muss automatisiert sein, Explosion der Testfälle verhindern
- Testprozess parallel zu jeder Entwicklungsphase, z.B. Um Testbarkeit zu garantieren
- Identifying correct outputs
- direkte Verifikation (falls möglich)
- redundante Berechnungen, Konsistenz Checks, Redundanzen überprüfen
Engineering Criteria for Technologies
- OO bringt spezielle Fehlermöglichkeiten, die auch speziell z.B. Mit polymorphen Pfaden in Grafen. z.B.
- State definition anomaly: überschreibende Method behandeln state inconsistent
- inconsistency wegen Variable hinding