Page 1
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
© Vector Software, Inc. © Vector Software, Inc. © Vector Software, Inc. © Vector Software, Inc. © Vector Software, Inc. © Vector Software, Inc.
Wie System Simulation und Test Automation die agile Software Entwicklung beschleunigt
Ingo Nickles Field Application Engineer
Vector Software, Inc. www.vectorcast.com
[email protected]
Page 2
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
[email protected]
Agenda
> Agile und System Simulation > Wasserfall vs. Scrum
> Grundlagen des Testens > Code Coverage
> Automatische Testfall Erstellung > Basis Path
> Agile und Testen > Scrum und Test Driven Development
> Automatische Testfall Ausführung > Change Based Testing
Page 3
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
> > > > System Simulation
Page 4
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
[email protected]
Warum Simulation?
Manifest für Agile Softwareentwicklung
Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen.
Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:
Individuen und Interaktionen mehr als Prozesse und Werkzeuge Funktionierende Software mehr als umfassende Dokumentation Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
Reagieren auf Veränderung mehr als das Befolgen eines Plans
Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.
Page 5
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
[email protected]
Agiles Testen im Vergleich zum Wasserfall-Testen
Maintenance
Design
Anforderung
Test
Implemen-tierung
Maintenance
Design
Anforderung
Test
Implemen-tierung
Produktentwicklung häufig parallel für und
Software
Hardware
Testen der Software setzt Verfügbarkeit der Hardware voraus
Zeit
Feste Termine
Schwarzer Peter Spiel
Trennung Entwickler<->Tester
Agil nicht möglich
Page 6
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
[email protected]
Agile SW Entwicklung: Scrum
Zeit
Produkt Backlog
Sprint Backlog
R E
V I E
W
D
E M
O
T
E S T
C O
D I N
G
D E
S I G
N
P L
A N
U N G
Sprint Backlog
R E
V I E
W
D
E M
O
T
E S T
C O
D I N
G
D E
S I G
N
P L
A N
U N G
Sprint Backlog
R E
V I E
W
D
E M
O
T
E S T
C O
D I N
G
D E
S I G
N
P L
A N
U N G
Mehrere Test- und Demo-Phasen
Koordination mit HW schwierig bis unmöglich
Simulation macht Scrum erst möglich
Page 7
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
[email protected]
Beispiele für Simulatoren
> Viele Entwicklungsumgebungen stellen einen Simulator zur Verfügung > IAR Embedded Workbench
> Keil µVision
> Renesas
> Tasking
> TI Code Composer Studio
> Wind River VxWorks
> ...
> Freie Simulatoren (mit Vorsicht zu genießen...) > Lauterbach (trace32)
> QEMU (Quick Emulator)
> ...
> Erwerbbare Simulatoren > Simics (Wind River)
> ...
Page 8
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
[email protected]
Simulator oder echte Hardware?
> Simulation auch dann sinnvoll wenn HW verfügbar ist > HW hat limitierte Anzahl von Flashzyklen
> Evtl. limitierte Anzahl von Boards
> Ausführung von Testfällen auf echter HW langsamer (Flashzeiten)
> Während der Testfall-Entwicklung Simulation sehr empfehlenswert
> Simulation kann den Test auf der echten HW nicht ersetzen > HW Verhalten kann vom Simulator abweichen
> Simulator kann fehlerhaft sein
> Simulator Test auf HW wiederholen > Z.B. einmal/Tag(Woche) oder sobald HW verfügbar
> Testverlagerung von Simulator auf HW muss einfach sein
> Test Automation empfohlen
Page 9
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
> > > > Testen - Grundlagen
Page 10
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
> Test-Ebenen: Unit- Integrations- und System-Level Tests
> Testfall = In- und Out-Werte > Eingabe Werte
> Erwartete Soll Werte
> Requirements!
> Testen hat einen destruktiven Ansatz > nicht so sehr in Agile wie im Wasserfall
> Teste den unveränderten Code
> Teste unter realen Bedingungen > Ziel-Hardware
> Produktiv-Entwicklungsumgebung
Grundlagen
Page 11
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
[email protected]
Zeit
Ko
sten
> Gefordert von Standards > MISRA, MISRA C++
> IEC 62304
> FDA
> Erhöhen der SW Qualität > Spart Zeit und Geld
> Verbessert “Time-To-Market”
> Verbesserte Kundenzufriedenheit
> Verbesserte Mitarbeiterzufriedenheit
> Erleichtert Re-Use und Re-Design von Code
> Im agilen Prozess vorgesehen
Testen – warum?
Kosten für die Fehlerbeseitigung im Verhältnis zur Zeit die seit Fehlereinführung vergangen ist 1. Fehler vermeiden
2. Fehler so früh wie möglich finden
Page 12
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
[email protected]
Code Coverage / Code Abdeckung
> Wichtige Metrik beim Testen > Code Coverage Varianten
> Function coverage > Function call coverage > Statement coverage > Decision coverage > Condition coverage > Condition/decision coverage > Modified condition/decision coverage (MC/DC)
Beispiel für Statement coverage
Beispiel für Statement und Decision coverage
Page 13
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
[email protected]
MC/DC, Analyse und Test
Cond. a Cond. b Cond. c Decision Result
True True True True
True True False False
True False True False
True False False False
False True True False
False True False False
False False True False
False False False False
Code Beispiel
if (a and b and c) Vereinfachter Ausdruck:
Wahrheitstabelle
Beispiel für MC/DC Code coverage:
MC/DC Äquivalenz Paar für condition a
MC/DC Äquivalenz Paar für condition b MC/DC Äquivalenz Paar für condition c
Page 14
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
[email protected]
Test - Ebenen
System Test
Modul Test
Integrations Test
Source code
Files (.c, .cpp, .h)
> Modul Test (Unit Test) > Test eines einzelnen Files isoliert vom restlichen Code
> Black Box: 100% Low Level Requirements
> White Box: Ziel ist 100% Code Coverage
> Integrations Test > Testen des Zusammenspiels mehrerer Files
> Black Box: 100% High Level Requirements
> White Box: ca 85% Code Coverage
> System Test > Testen aller Files. Testen der gesamten Applikation
> Black Box:
> 100% System Requirements
> Ca. 50% Code Coverage
> White Box: Ca 70% Code Coverage sind möglich
Page 15
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
> > > > Automatische Testfall Erstellung
Page 16
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
> Testen ist automatisierbar in Bezug auf > Testfall Erstellung
> Testfall Ausführung
> Test-Automation ist wärmstens empfohlen, z.B. weil... > Dies auch die Standards so sehen (FDA)
> Jeder Iterationsschritt bedeutet erneutes Testen
> Regressions Test
> Kontinuierliche Integration (CI)
> Die Akzeptanz des Testens beim Mitarbeiter steigt
> Stupides wiederholen des gleichen Test-Sets ist unzumutbar
> Durch Automation sichergestellt ist, dass die Tests auch gemacht werden
> ...was leider nicht selbstverständlich ist....
> Was automatisierbar ist sollte auch automatisiert werden
Testen und Automation
Page 17
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
[email protected]
Test-Kategorien und Automatisierbarkeit
(1) Statische Codeanalyse > Überprüfung des Code auf formale Korrektheit > Einhalten von Codierungsregeln > Analyse von Speicher-Verwendung. Suche nach üblichen Fehler-Ursachen.
(2) Funktionales Testen – Überprüfung der Requirements > Führe den Code aus und prüfe ob er tut was er soll > Metrik der Test-Vollständigkeit > Möglich als Unit-, Integrations- und System-Test
(3) Dynamisches Code basiertes Testen: Code Abdeckung > Code Ausführung mit Messung der Code Abdeckung > Metrik der Test-Vollständigkeit > Erreichen von 100% Code Abdeckung (Function, Statement, Branch, Decision Coverage)
(4) Dynamisches Code basiertes Testen: Stabilität > Analysiere Funktions Schnittstellen und globale Variablen > Sei gemein. Teste mit MIN, MAX, MIN-1, MAX+1, NULL-PTR, INF, NAN > Fault Injection
Der Computer soll die Arbeit machen. Die Test-Ausführung ist immer automatisierbar. Wie sieht es mit der Testfall-Erstellung aus?
Test-Kategorien und Automatisierbarkeit
Page 18
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
[email protected]
Basis Path, Analyse und Test
> Eine Herausforderung beim Modul-Test: Ein guter Satz von Testdaten
> Redundanzen eliminieren > Gute Testfall Abdeckung > Effektiver testen
> Basis Path Testfälle > Mischung aus Pfad und Branch Testen > Testen aller linear unabhängigen Pfade, ohne Iterationen
> Details folgen gleich > 100% Statement und Decision Coverage
> Build Instructions (Thomas J. McCabe) > Zeichne einen Kontrollflussgraphen > Kalkuliere die zyklomatische Komplexität > Wähle einen “Basis Satz” von linear unabhängigen Pfaden > Die Anzahl der linear unabhängiger Pfade ist gleich der zyklomatischen
Komplexität
Finde Testdaten, die die gefundenen Pfade durchlaufen
Page 19
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
[email protected]
> Zyklomatische Komplexität > Anzahl der „Decision-Points“ + 1
> In unserem Fall also 4
> Klassische Konstruktions-Empfehlungen betrachten die Pfad > A – B – C – E – F – H – I – J - L
> Einfacher: Darstellen der Decisions > D1:True – D2: True – D3: True oder T T T oder 1 1 1
> Alle möglichen Pfade durch den Code sind dann:
1. 1 1 1
2. 1 1 0
3. 1 0 1
4. 1 0 0
5. 0 1 1
6. 0 1 0
7. 0 0 1
8. 0 0 0
> In unseren “Basis Path” – Set dürfen nur Pfade die nicht durch linearkombinationen bereits vorhandener Pfade darstellbar sind
Automatische Testfall-Ausführung
B
E
C D
A
H
F G
I
L
J K
D1
D2
D3
Schritt 1 BP-Set 1. 1 1 1
Schritt 4 BP-Set 1. 1 1 1 2. 1 1 0 3. 1 0 1 8. 0 0 0
Schritt 3 BP-Set 1. 1 1 1 2. 1 1 0 3. 1 0 1
1+3 = 0 1 0 = 6 2+3 = 0 1 1 = 5
1+2+3 = 1 0 0 = 4
Schritt 2 BP-Set 1. 1 1 1 2. 1 1 0
1+2 = 0 0 1 = 7
Page 20
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
> > > > Agile und Testen
Page 21
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
> Agile heißt nicht... > „Quick and Dirty“
> Schlechte Qualität
> Unstrukturiert
> Keine Requirements
> ...sondern... > „Funktionierende Software“
> Entwicklung und Test rücken näher zusammen
> Jeder Iterationsschritt bedeutet erneutes Testen
> Regressions Test
> Kontinuierliche Integration (CI)
> Testen ist zentraler Bestandteil des Entwicklungsprozesses
> Im klassischen Entwicklungsprozess wird die Testphase gerne als Puffer zum Release Datum gesehen
> TDD
Testen und Agilität
Page 22
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
[email protected]
Test Automation am Beispiel: Scrum
Zeit
R E
V I E
W
D
E M
O
T
E S T
C O
D I N
G
D E
S I G
N
P L
A N
U N G
R E
V I E
W
D
E M
O
T
E S T
C O
D I N
G
D E
S I G
N
P L
A N
U N G
R E
V I E
W
D
E M
O
T
E S T
C O
D I N
G
D E
S I G
N
P L
A N
U N G
> Testfälle aus Sprint n sollten auch in Sprint n+1 noch funktionieren > Bei Code-Änderungen sollten immer auch Testfälle berücksichtigt werden > Code und Testfälle „synchron“ halten > Code-Review und Testfall-Review sinnvoll
> Automatisierbarkeit in Bezug auf > Testfall Ausführung
> Sprint n+1 = Continuous Integration > Testfall Erstellung
Page 23
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
[email protected]
Test Automation am Beispiel Test Driven Development
> „Testgetriebene Entwicklung“ (TDD) ist eine agile Software Entwicklungsmethode
> Wiederholung eines kurzen Entwicklungs-Zyklus‘
> Erst den Testfall, dann denn den Code erstellen 1) Testfall schreiben
2) Testfall ausführen: FAIL
3) Source Code schreiben
4) Testfall ausführen : PASS
5) Alle Testfälle ausführen: PASS
6) Re-design (refactor)
7) Alle Testfälle ausführen : PASS
Page 24
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
[email protected]
Test Driven Development - Ablauf
Alle Tests PASS &
Gutes Design
1 oder mehr Tests FAIL &
Gutes Design
Alle Tests PASS &
Schlechtes Design
Neuer Testfall
Testfall ausführen PASS
FAIL
PASS
Alle Testfälle
ausführen
Code Änderung
FAIL
FAIL
Alle Testfälle ausführen
Re-Design Step 1..n
PASS
PASS
Page 25
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
> > > > Projekt Testumgebung und Change Based Testing (CBT)
Page 26
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
[email protected]
Modul Test Applikation
Wie sollte eine Modul Test Umgebung gebaut werden
File unter Test
Dummy- Funktionen
(Stubs / Mocks)
“Echte” Funktionen
(Source code oder .obj files)
Test Treiber
main()
Source code
Files (.c, .cpp, .h)
Test Daten IN / OUT
Reports
PASS/FAIL
Code Coverage 100%
IN: - Funktion Parameter - Globals - Stub Returns OUT: - Funktion Returns - Globals - Stub Parameter
Test Daten
Page 27
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
[email protected]
Test Umgebungen in einem Projekt
Source code
Files (.c, .cpp, .h)
1 Modul Test Umgebung pro File
Mehrerer Integrations Test Umgebungen mit 2 oder mehr Files
1 oder mehr System Test Umgebungen
Page 28
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
[email protected]
Testen verschiedener Varianten
Source code
Files (.c, .cpp, .h)
> Oft wird der selbe Source Code beim Kunden in verschiedenen Konfigurationen eingesetzt
> Verschiedene compile-defines
> Verschiedene compiler options
> Verschiedene Include-Pfade
> Verschiedene Ziel-Plattformen
Alle Tests müss(t)en in allen möglichen Konfigurationen
durchgeführt werden
Page 29
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
[email protected]
Software Änderungsprozess in der Praxis
Source code
Files (.c, .cpp, .h)
> Software Entwickler ändert Code > Bug fixes
> Neue feature
> Aigler Iterations-Schritt
> Code Änderung muss getestet werden > Modul-, Integrations, System – Test
> Ausführen aller Testfälle in allen Konfigurationen ist unmöglich > In der Praxis wird der System Test oft in nur einer Konfiguration ausgeführt
> Oft auch der Modul Test in nur einer Konfiguration
> Aufgrund der langen Laufzeit werden Integrations Tests und komplette System Tests nur sporadisch durchgeführt
> Fehler müssen zum verantwortlichen Entwickler zurückverfolgt werden
> Entwickler muss sich wieder in seine Code Änderung rein-denken und den Fehler fixen
> Dadurch, dass der Code in nur einer Konfiguration getestet wird bleibt ein hohes Fehler-Rest-Risiko in ungetesteten Konfigurationen
Page 30
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
[email protected]
Was ist Change Based Testing?
Source code
Files (.c, .cpp, .h)
> Änderungs basiertes Testen
> Nur Test Umgebungen neu bilden, die von Code Änderungen betroffen sind > Viele Modul- und Integrations-Test-Umgebungen sind von Source Code Änderungen nicht betroffen
> Nur Testfälle ausführen, die von Code Änderungen betroffen sind > Das Testfall Management System muss Code Änderungen erkennen
> Z.B. per Zeitstempel, Checksumme, Daten-Austausch mit SW-Verwaltungs-Tool
> Testfälle müssen den Code Zeilen zugeordnet sein
> Z.B. per Code Coverage Information
> Auch innerhalb eines Files sind oft nur wenige Funktionen von Code Änderungen betroffen
> Dementsprechend müssen auch nur wenige Testfälle je File ausgeführt werden
> Gleiches gilt für Änderungen an Testfällen > Nicht nur Source Code ändert sich. Geänderte Testfälle in allen Konfigurationen ausführen.
Page 31
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
[email protected]
Welche Testumgebungen müssen neu gebildet werden?
Modul Test Umgebung
Integrations Test Umgebung
System Test Umgebung Source code
Files (.c, .cpp, .h)
Page 32
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
[email protected]
Welche Testfälle müssen ausgeführt werden?
Modul Test Umgebung
Integrations Test Umgebung
System Test Umgebung Source code
Files (.c, .cpp, .h)
Page 33
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
[email protected]
Welche Testfälle müssen ausgeführt werden?
Modul Test Umgebung
Integrations Test Umgebung
System Test Umgebung Source code
Files (.c, .cpp, .h)
Page 34
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
[email protected]
Regressions Test in allen Varianten...
> ...ist jetzt möglich
> Reduzierte Anzahl von Test Umgebungen die gebildet werden müssen
> Reduzierte Anzahl von Testfällen die ausgeführt werden müssen
> Änderungs basierte Test-Auswahl muss pro Konfiguration erfolgen
Source code
Files (.c, .cpp, .h)
Page 35
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
[email protected]
> Reduzierte Test Ausführungs Zeiten
> Jeder Entwickler kann vor Code-Einchecken alle (notwendigen) Testfälle ausführen
> CBT Report zeigt welche Testfälle von Code Änderung betroffen sind => Evtl. diese Testfälle anpassen und hier neue Testfälle erstellen
> Keine Integrations-Test-Fehler die erst Wochen nach einer Code Änderung auffallen
> Verbesserte Nutzung der Test-Infrastruktur
> Verbesserung “Time to market”
> Verbesserung der Software-Qualität
Change Based Testing Vorteile
Zeit
Ko
sten
Page 36
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
[email protected]
Beilspiel einer CBT Test-Umgebung: CBT Report
Page 37
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
[email protected]
Connect With Us
Proven Solutions for Reliable Software
Americas 1351 South County Trail Suite 310 East Greenwich, RI 02818 United States of America T: +1 401 398 7185 F: +1 401 398 7186 E: [email protected]
EMEA Golden Cross House 8 Duncannon Street London WC2N 4JF, UK T: +44 203 603 0120 F: +44 207 022 1651 E: [email protected]
Deutschland St. Töniser Str 2a 47906 Kempen Deutschland T: +49 2152 8088808 F: +49 2152 8088888 E: [email protected]
Asia Pacific Rm 403, Building 6 No.88 Daerwen Rd Zhangjiang Hi-tech Park Pudong New Area Shanghai 201203 China T: 21- 3126 8126 F: 21-5132 8526 E: [email protected]
v e c t o r c a s t . c o m