Verlässliche Systeme – Test von Software
9.1 Grundlagen
Verlässliche Systeme
Wintersemester 2015/2016
9.1 Grundlagen
Nochmals: Verifikation und Test in der SW-Entwicklung
Fehler
Verlässliche Systeme
Test
keine
Fehler
gefunden
9. Kapitel
Vorstellung
des
Kunden
Test von Software
Anforderungsspezifikation
Formale
Spezifikation
Programmentwurf
Prof. Matthias Werner
Verifikation
korrekt
Professur Betriebssysteme
Fehler
WS 2015/2016 · M. Werner
Verlässliche Systeme – Test von Software
9.1 Grundlagen
osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Test von Software
9.1 Grundlagen
Existenz von Fehlern
Herausforderungen
I
Neue Technologien vergrößern (auch) oft die Komplexität des Testens
I
Merke
I
Softwaretests beweisen nie die Korrektheit von Programmen, sondern höchstens die
Existenz von Fehlern!
I
I
Dynamisches Verhalten
Nebenläufige Ausführung
Komplexe Sprachen
Paradigmen wie Objektorientierung
I
Trotzdem werden Software-Tests häufiger eingesetzt als Software-Verifikation:
I
I
I
Zu großer Aufwand für Verifikation
I
Mangelnde Fähigkeit/Kenntnis der Verifikationsmethoden
I
Keine klare Spezifikation (Programmierer weiß“ ja, was gemeint ist...)
”
I
3 / 22
osg.informatik.tu-chemnitz.de
Nachnutzung getesteter Komponenten in einem anderen Kontext
Vererbung
...
In diesem Kapitel
I
I
I
WS 2015/2016 · M. Werner
2 / 22
Überblick
Ansätze
Testautomatisierung
WS 2015/2016 · M. Werner
4 / 22
osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Test von Software
9.1 Grundlagen
Verlässliche Systeme – Test von Software
9.1 Grundlagen
Grundidee
Fehler-Test-Korrelation
I
I
Erzeuge irgendwelchen Input
I
Lasse Programm laufen
I
Vergleiche Ergebnis mit dem erwarteten Ergebnis
I
Probleme:
I
I
I
Die Wahrscheinlichkeit für die Existenz von Fehlern nimmt nicht mit der Zahl der
gefundenen Fehler ab
Welcher Input?
Abdeckung?
Wann genug?
á es ist i.d.R. unmöglich, alle möglichen Eingabevarianten zu testen (Komplexität!)
I Ausnahme: erschöpfendes Testen
I
Testen findet üblicherweise spät im Projekt statt
Quelle: G.J. Myers, The Art of Software Testing, John Wiley & Sons (2004)
I
WS 2015/2016 · M. Werner
5 / 22
osg.informatik.tu-chemnitz.de
Achtung: Abstumpfungsgefahr
WS 2015/2016 · M. Werner
Verlässliche Systeme – Test von Software
9.1 Grundlagen
6 / 22
osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Test von Software
9.2 Ansätze
9.2 Ansätze
Frühes Testen
Whitebox vs. Blackbox
I
Je später ein Fehler entdeckt wird, deso höher sind die entstehenden Kosten
I
Beispiel: Kostenfaktor für Fehleraufdeckung in verschiedenen Phasen des
Entwicklungsprozesses*
Phase im
Entwicklungsprozess
Spezifikation
Spezifikation
Fehler in...
Entwurf
Implementation
1
Whitebox á Unit-Tests
I
Konzept: Bei möglichst kleinen Komponenten möglichst viele Pfade testen
I
Vorteil: Kenntnis interner Vorgänge bringt höchste Fehleraufdeckung
Nachteil:
I
Entwurf
3
1
Implementation
5 – 10
10
I
1
I
Systemtest
10
15
10
Post-Release
10 – 100
25 – 100
10 – 25
Test werden i.d.R. vom Programmierer entworfen (jemand anders durchschaut den
Code nicht)
Aber: Jemand, der einen Fehler macht, erkennt ihn selten (Vorbelastung)
* Quelle: STEVE MCCONNELL, Code Complete (2nd ed.),Microsoft Press, 2004
WS 2015/2016 · M. Werner
7 / 22
osg.informatik.tu-chemnitz.de
WS 2015/2016 · M. Werner
8 / 22
osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Test von Software
9.2 Ansätze
Verlässliche Systeme – Test von Software
9.2 Ansätze
Whitebox vs. Blackbox (Forts.)
Whitebox vs. Blackbox (Forts.)
Blackbox á Funktionstests
I
I
Konzept: Übereinstimmung mit externer Spezifikation testen
I
Vorteil: Tester werden nicht durch die Kenntnis des internen Designs beeinflusst
Nachteile:
I
I
I
I
I
I
Explizite Spezifikation wird benötigt
Deckt i.d.R. nur einen kleinen Teil der möglichen Fälle ab
WS 2015/2016 · M. Werner
9 / 22
I
osg.informatik.tu-chemnitz.de
Software testing still remains an art, since the first day. We still don’t know how to
”
make it a science.“
J. PAN, CMU
Dies gilt insbesondere für die Generierung von Testfällen
Problem: Vorwissen
I
Vorwissen hilft kritische Fälle zu erkennen und damit Fälle einzuschränken
Vorwissen verhindert die Erkennung kritischer Fälle und eleminiert sie
In der Regel ist die Komponente oder die Voraussetzung fehlerhaft, an der keiner
”
gezweifelt hat.“
Software-Engineering Ableitung vom FINAGLES 3. Korollar zu MURPHYS Gesetz
WS 2015/2016 · M. Werner
11 / 22
osg.informatik.tu-chemnitz.de
Generierung von Testfällen und -kriterien (Forts.)
I
I
10 / 22
Verlässliche Systeme – Test von Software
9.2 Ansätze
Generierung von Testfällen und -kriterien
I
verwendete Algorithmen
interne Datenstrukturen
Modul-Strukturen und -abhängigkeiten
WS 2015/2016 · M. Werner
Verlässliche Systeme – Test von Software
9.2 Ansätze
I
In der Praxis wird meist eine Mischung aus Blackbox- und Whitebox-Test
angewendet
Graybox Testing: Blackbox mit zusätzlichen Informationen über
osg.informatik.tu-chemnitz.de
Unabhängig von der nötigen Intuition und Kreativität gibt es
Standardherangehensweisen, z.B.:
WB
Szenario-basiertes Testen
Risikobasiertes Testen
Bedingungstabellen
BB
X
X
X
Pfadabdeckung
X
Statementabdeckung
X
Branch-Abdeckung
X
Datenflußanalyse
Grenzwertanalyse
All pairs
X
X
X
X
X
Adhoc-Tests
X
X
WS 2015/2016 · M. Werner
Idea
wähle Testfälle nach Einsatzszenarien aus
wähle Testfälle nach Auswirkung
beschreibe Ursache-Wirkungskorrelation mit Hilfe
von Bedingungstabellen
wähle Testfälle so, dass jeder Ausführungspfad abgedeckt ist
wähle Testfälle so, dass jedes Statement abgedeckt
ist
wähle Testfälle so, dass bei jeder Verzweigung jeder
Weg mindestens einmal getestet wird
teste entlang des Datenflusses
teste beide Seiten von Unstetigkeitspunkten
teste für eine Menge von Features alle Zweierkombinationen
nutze Intuition und gesunden Menschenverstand
12 / 22
osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Test von Software
9.2 Ansätze
Verlässliche Systeme – Test von Software
9.2 Ansätze
Testphasen
Integrationstest
Systemtest
I
Komponententest
I
Integrationstest
Releasetest
Idee: Stückweise Vergrößerung des Testobjekts
Hauptansätze:
I
I
I
typischerweise
durchgeführt von:
Unabhängigen
Testteams
Entwickler
WS 2015/2016 · M. Werner
13 / 22
osg.informatik.tu-chemnitz.de
WS 2015/2016 · M. Werner
Verlässliche Systeme – Test von Software
9.2 Ansätze
Steuerprogramm wird zuerst getestet
I
Module werden nacheinander integriert
I
Schwerpunkt auf Interfaces
Vorteile:
I
I
I
Frühe Erkennung der Funktionsfähigkeit
I
Schwerpunkt auf (Modul-)Funktionalität und Performance
Vorteile:
I
Es wird kein Test-Treiber (Integrationsframework) benötigt
Interface-Fehler werden früh aufgedeckt
I
I
15 / 22
I
osg.informatik.tu-chemnitz.de
Es werden keine Module-Stubs benötigt
Kritische Komponentenfehler werden früh erkannt
Nachteile:
I
Es werden Module-Stubs benötigt
Kritische Komponentenfehler werden spät erkannt
WS 2015/2016 · M. Werner
I
I
Nachteile:
I
osg.informatik.tu-chemnitz.de
Bottom-up Integrationstest
I
I
14 / 22
Verlässliche Systeme – Test von Software
9.2 Ansätze
Top-down Integrationstest
I
Top-down Integrationstest
Bottom-up Integrationstest
Regressionstest
Es werden Test-Treiber (Integrationsframework) benötigt
Interface-Fehler werden spät erkannt
WS 2015/2016 · M. Werner
16 / 22
osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Test von Software
9.2 Ansätze
Verlässliche Systeme – Test von Software
9.2 Ansätze
Regressionstest
I
I
Testet die Auswirkungen von neuen Änderungen auf gesamten bisher integrierten
Code
Gemeinhin werden zwei Testmengen definiert: Gesamttest und kritische
Untermenge
I
I
I
I
I
Gesamttest wird gelegentlich durchgeführt
Kritische Untermenge bei jedem Durchlauf
Neben der funktionalen Korrektheit spielen auch nichtfunktionale Eigenschaften
eine Rolle
Testkategorien in diesem Bereich:
I
I
I
Schnellere Eingrenzung von Fehlerursache
I
Nachteil:
I
Performance-Tests
Stresstests
I
Vorteil:
I
I
Nichtfunktionale Eigenschaften
I
Lasttests
Speichererschöpfungstests
Sicherheitstest
Robustheitstest
Es ist schwer zu entscheiden, was zur kritischen Untermenge gehört
1
WS 2015/2016 · M. Werner
17 / 22
osg.informatik.tu-chemnitz.de
WS 2015/2016 · M. Werner
Verlässliche Systeme – Test von Software
9.3 Automatisierung
Verlässliche Systeme – Test von Software
9.3 Automatisierung
What ADLT Is Not
9.3 Automatisierung
Beispiel: ADL
Automatisierung
I
Testen beinhaltet häufig wiederkehrende Vorgänge
I
Nur kleinere Projekte sollten zu Fuß“ getestet werden
”
Automatisierung des Testvorganges
Verschiedene Teile des Testvorganges können (semi-)automatisiert werden:
I
I
I
I
I
I
Assertion Definition
While ADLT is a powerful unit-testing tool, it cannot do all tasks associated
with testing. ADLT was specifically designed not to be a test harness or
debugger. ADLT relies upon the Test Environment Toolkit (TET) test harness to
Language
(ADL) Translation
Systemand clean-up structure.
provide
test management,
building, execution,
Formal Specification
of Software Component
(ADL File)
I
I
ADLT helps in the18implementation
of new software
by generating header
/ 22
osg.informatik.tu-chemnitz.de
files containing declarations of the elements in the specified
component—the constituent functions, variables, constants, and type
definitions. Since ADL specifications are not embedded in the components
to be tested or documented, ADLT can be used with either new software or
existing, already-compiled components.
Generierung von Test(mustern)
Instrumentierung des Codes
Testdurchführung und -protokollierung
Testauswertung
Es existieren jede Menge Tools, die eine Automatisierung von einer oder mehrere
Phasen des Testvorgangs unterstützen
á Liste auf http://www.testingstuff.com/tools.html
ADLT
Implementation
of
Functions Under Test
19 / 22
osg.informatik.tu-chemnitz.de
Test Code
Data Factory
and
Auxiliary Functions
Test Program
Programmer-Supplied
File
WS 2015/2016 · M. Werner
Formal Test Data
Description
(TDD File)
WS 2015/2016 · M. Werner
Figure 1-1
ADLT-Generated
File
High-level view of ADLT test generation.
20 / 22
Executable File
osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Test von Software
9.3 Automatisierung
Verlässliche Systeme – Test von Software
9.3 Automatisierung
Beispiel: Testdurchführung in Java
Beispiel: Testdurchführung in Java (Forts.)
I
I
Verschiedene Tools, z.B. JUnit, TestNG, JTiger
I
Dabei ist JUnit am ältesten und daher auch vermutlich am bekanntesten und hat
die meisten Erweiterungen/Plugins, z.B. Cactus, DJUnit, Infinitest
I
Vorgehen:
I
I
I
I
I
Asserts“ werden abgefangen und ausgewertet
”
Nutzung von Java-Annotationen zur Definition und der Verwebung“ von
”
Test-Routinen
Automatische Testdurchführung
Integration in Eclipse
Test von Ausnahmebedingungen
Zusicherung (Assertion):
import java.util.*;
...
public void test average simple ()
{
Vector nums = new Vector();
nums.add(new Integer(3));
assertTrue(MathOps.average(nums) == 3.0);
}
I
Exception-Test:
@Test(expected= IndexOutOfBoundsException.class)
public void empty() {
new ArrayList<Object>().get(0);
}
á mehr in der Übung
WS 2015/2016 · M. Werner
21 / 22
osg.informatik.tu-chemnitz.de
WS 2015/2016 · M. Werner
22 / 22
osg.informatik.tu-chemnitz.de
© Copyright 2024 ExpyDoc
