AO08: Paul Amman, Jeff Offutt. Introduction to software Testing

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