wie system simulation und test automation die agile ... · die agile software entwicklung...
TRANSCRIPT
© 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
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
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
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
> > > > System Simulation
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
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.
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
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
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
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
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
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)
> ...
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
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
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
> > > > Testen - Grundlagen
© 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
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
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
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
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
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
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
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
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
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
> > > > Automatische Testfall Erstellung
© 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
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
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
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
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
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
> 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
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
> > > > Agile und Testen
© 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
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
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
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
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
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
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
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
> > > > Projekt Testumgebung und Change Based Testing (CBT)
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
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
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
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
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
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
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
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
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
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.
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
Welche Testumgebungen müssen neu gebildet werden?
Modul Test Umgebung
Integrations Test Umgebung
System Test Umgebung Source code
Files (.c, .cpp, .h)
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
Welche Testfälle müssen ausgeführt werden?
Modul Test Umgebung
Integrations Test Umgebung
System Test Umgebung Source code
Files (.c, .cpp, .h)
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
Welche Testfälle müssen ausgeführt werden?
Modul Test Umgebung
Integrations Test Umgebung
System Test Umgebung Source code
Files (.c, .cpp, .h)
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
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)
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
> 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
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
Beilspiel einer CBT Test-Umgebung: CBT Report
© V
ecto
r So
ftw
are,
Inc.
©
Vec
tor
Soft
war
e, In
c.
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