Lit / PY08

PY08: Mauro Pezzè, Michal Young. Software Testing and Analysis

2008. John Wiley & Sons

  • Das Halting Problem einer Turing Maschine ist unentscheidbar, und die Tests der meisten Programme sind ebenso hart
  • unvollständige Verifikationen entweder pessimistische (falsche Negatives: man muss aus falsche Fehlermeldungen die echten rausfiltern) oder optimistisch (zu wenige Fehlermeldungen)
  • Validation: auswerten wiewei Software User real needs erfüllt
  • Verifikation: überprüfen ob Implementation mit Spezifikation übereinstimmt (auf irgendeiner Ebene)
  • V-Modell:
    • actual needs, constraints / requirements ==> user acceptance test
    • system spec ==> system test
    • Subsys desing spec ==> integration test
    • unit/component specs ==> unit/module test
  • oracle: inspect result of test und Entscheid ob satisfied or failed
  • Basic Principles
    • Sensitivity: Versuch das zufällige Fehler häufiger werden (damit sie bei Tests eher entdeckt werden) also defensiv programmieren (asserts usw.)
    • Redundancy: maschinell überprüft oder generiert billiger als Testen, z.B. Statische TypeSystem
    • Restriction: ein schwierig zu testende Property durch eine einfacher zu testende Verschärfung ersetzen (z.B. Nur initialiserte Variabeln lesen durch am Anfang initialisert, oder Serialisierbarkeit durch ein Serialisierungsprotokoll)
    • Partition: divide und conquer: z.B. In Teilprobleme auflösen, oder Modell bilden und dort verifizieren
    • Visibility: dass man sieht was passiert (z.B. HTTP hat lesbare Textmeldungen)
    • Feedbacl
  • endliche Modelle: ControlFlowGraphs, CallGraphs, endliche Automaten
  • dependence and dataFlowModels
  • Symbolic Execution and Proof of Properties
  • Finite State Exploration: State Space Exploration mit Safety and Liveness Eigenschaften, relational Algebra
  • Test case selection and adequacy
    • test case: input, execution condition, und pass/fail criterion
    • test oder test execution: durchführen eines test case
    • test suit: Menge von Test cases
    • test case specification: Ein requirement, das durch einen oder mehrer test cases erfüllt werden kann
    • test obligation: Teil einer test case specification
    • adequcy criterion: ein Prädikat, auf einem Programm – Test suite Paar. Satisfied oder nicht
    • adqequacy criteria Vergleichen: z.B. Subsume (umfassen) ==> kannn benutzt werden um Qualität einer TestSuite zu messen, oder zusätzliche TestCases zu finden
  • functional testing
    • function test cases können und sollen schon in der requirements Phase entworfen werden
    • z.B. Random oder Partitionierung des Inputspaces
  • Combinatorial Testing
    • Category-Partition Testing: Aufteilung in unabhängig testbare Feature, repräsentative Values bestimmen und Test case specifizieren
    • pairwise combination testing – statt alle Kobminationen nur paarweise kombinieren
    • catalog-based testing: einen Katalog der input values (für eine Variable), z.B. Integer Variable mit einem Intervall: einen mitteleren Wert, die beiden Grenzwerte, und deren äussere Nachbarn
  • Structural Testing: Testfälle aus Programmstrukturen ableiten
    • Statement Coverage
    • Branch Coverage
    • Condition Testing (jede Klausel innerhalb jedes Prädikates)
    • Path testing: brauchen spezielle Kriterien für Loops (z.B. Jeder Loop muss 0-, 1- und mehrmals durchlaufen werden)
    • Call Coverage
  • DataFlow Testing
    • Definition Use - Coverage
      • jedes DU pair (verbunden über Definition-free (ControlFlow) path) muss durchlaufen werden
  • Model based testing
    • endlich Automation: z.B. Transition Coverage
    • Entscheidungstabellen
    • Test cases von ControlFlow oder Dataflow Graphen ableiten oder Grammatiken ableiten
  • Testing object-oriented software
    • State Dependent Behaviour: Objekt haben einen State, der Methoden beeinflusst
    • Encapsulation (Test benötigen Zugriff auf hidden variables)
    • inheritance
    • polymorphismus und dynamic binding
    • abstract classes
    • genericity
    • exception handling
    • concurrency
    • z.B. Mit folgenden Schritten
      • Intraclass (Instanzierungen für abstrakte class, inherited constructors und methods, state machine tests, structural tests für class source, exceptions, polymorphic calls
      • Interclass: Hierarchy von KlassenClustern für incremental tests, für jeden Cluster: funktional, dataFlow, exceptionHandling, Polymorphismus
      • System und Acceptance: wie üblich
  • Fault Based Testing: mechanisch Fehler in Programme einfügen und mit testSuite prüfen
    • competent programmer hypothesis: Programmierer machen kleinere Fehler (die einfachen Mutationsoperatoren ähnlich sind)
    • coupling effect hypotheses: tests für einfache Fehler entdecken auch komplexe.
    • Fault Based Adquacy Criteria: genereate mutatants, führe TestSuite aus, wieviele Mutanten bleiben unentdeckt
    • Qualitätsmass: Verhältnis von endeckten zu unentdeckten Mutanten entspricht dem Verhältnis von bis jetzt total entdeckten Fehlern zu noch in der Software vorhandenen Fehlern
  • Test Execution
    • aus test case specicification test cases abzuleiten kann mechanisch machbar sein, oder Genialität und Scaffolding benötigen
    • Scaffolding: Hilfscode um Testen zu erleichtern – liefern controllability und observability:
      • test driver (ersetzt caller)
      • test harness (ersetzt Teile der deployment Umgebung)
      • stubs (ersetzen benutzte Funktionalität der Software under test)
      • mock: einfachster stub der nur erwartete Aufrufe prüft
      • scaffolding Konstrukts können oft in SoftwareFunktionen verwendet werden (z.B. BusinessLogik mit Scripting statt GUI)
    • Oracles: entscheiden ob Test erfolgreich war oder nicht
      • comparision based (vergleich mit vorarsberechnetem Wert, anderer Implementation, oder Rückwärtsableitung des Inputs aus Output, oder partieller Test z.B. Neunerprobe)
      • selfchecks as oracles (assertions, z.B. Ein- ausschaltbar -> no sideeffects)
      • capture und replay
  • Inspection
    • manueller sozialer Prozess, einzeln oder in Gruppen
    • sozial Aspekt (Ausbildung, Know How Transfer, Project standards...)
    • CheckListen
    • pair programming
  • Protram Analysis
    • Symbolic Execution in Program Analysis: zu aufwendig für allgemeine Verifikation besser für spezielle Fehlerklassen (z.B. MemoryAccess oder Concurrency Faults)
    • Symbolic Testing: Variablenwerte auf wenige Aequivalenzklassen reduzieren (z.B. Null, not null)
    • Summaryzing Execution Paths, z.B. Endlicher Automat mit obigen Aequivalenzklassen und Transitions entsprechend gruppieren
    • MemoryAnalysis: instrumentierter Code, der MemoryZugriffe, LockingProtokoll usw. Überwacht
    • Extracting Behavior Model from Execution: aus TestExecution Modelle ableiten und analysieren
  • Planning and Monitoring the process: Ziel: Fehler möglichst früh erkennen, Risiken minimieren
    • Quality and Process – Qualität muss natürlich in GesamtenEntwicklungsProzess eingebettet sein (z.B. V-Model), typische Schritte für ein Element:
      • interne consistency checks
      • externe consistency checks
      • definieren von correctnes conjectures: z.B. Testresultate die Anforderungen an ander Produkte stellen
    • Test and Analysis Strategie: verschiedene Modelle, z.B. XP oder IBM Cleanroom
    • Test and Analysis Pläne
      • welche Qualitätsaktivitäten
      • Abhängigkeiten innerhalb Qualität und zwischen Qualität und Entwicklung, kritische Pfade und Abhängigkeiten
      • welche Resourcen
      • wie überwachen wir Prozess und Qualität des entstehenden Produkts
    • Risk Planning
      • personelle, technische (z.,B. Neuer DB-Release oder COTS (Commercial Of The Shelf Software) und Schedule Risks erraten, kontrollieren und überwachen
      • reduzieren durch zusätzliche oder frühere Tests usw.
    • Monitoring the Process
      • Fehler Statistiken: treten die Fehler in den erwarteten Häufigkeiten an den erwarteten Orten auf? Sinnvolle Lösungszeiten
      • orthogonal defect classification (ODC):
        1. wenn sie entdeckt werden Activity Executed, Trigger der Fehler zeigte, und impact auf custormer
        2. fix time: target, type (verschiedene Taxanomien), source und age der Software
        3. verschiedene Auswertung: Fault Type versus activities, triggers versus time usw.
    • Improving the Process
      • Root Cause Analysis (RCA) Ursache von Fehlern im Prozess suchen
    • Quality Team: verschiedene Modelle von voll integriert in Entwicklung (XP) bis absolut getrennt oder outsourcing
  • Integration and Component-based Software testing
    • Big Bang Testing: erst am Schluss
    • structural (abgeleiten von Programm/System) versus Featur oriented
    • top down testing braucht weniger driver/scaffolding dafür stubs
    • bottom-up umgekehrt
    • sandwhich or backbone Strategie: kombination von top down Analyse und BottomUp Prototypes. Z.B. Zum einbinden von COTS
    • critical module: anfangen mit Modules mit dem grössten Risiko
  • System, Acceptance andn Regression Testing
    • System Testing, soll unabhängige Tesets machen, nicht wiederholen. GesamSystemEigenschaften. Möglich sind auch lange Tests mit komplexen Auswertungen usw.
    • Acceptance Testing. Performance mit operational profile und sensitivity testing (gutmütiges Verhalten bei ¨Uberlast)
    • Usability – auch über den ganzen Zyklus von Usability Inspection und Prototypes (explatory testing) in der Reqirementsphase. Im AcceptanceTest Mit Vertretern verschiedener Usergruppen testen
    • Regression Testing: TestSuit muss mit Software maintain't werden.
      • Regression Test Selection: die gehabten Kriterien, aber redundante Tests sind teurer wegen Wiederholungen und Maintenance
      • Test Case Priorisierung und selektive Execution
  • Automating Analysis and Tests
    • Process Management mit verschiedenen Metriken
    • Tools für Test Case Generierung, static analysis and proof, cognitive aids (z.B. Im Editor, CrossRef, Visualisierungen usw.), Debugger, VersionControl usw.: geschickt Auswahl und Kombination von Tools
  • Documenting Analysis and Tests
    • Hauptkategorien: planning, specification (test suites), reporting:
      • Test Strategy Document
      • Anaysis and Test Plan
      • Test Design Specification Documents (-> Test suites)
      • Test and Analysis Reports
    • mature processes brauch Metadata in jedem Document