Wie System Simulation und Test Automation die agile ... · die agile Software Entwicklung beschleunigt Ingo Nickles Field Application Engineer Vector Software, Inc. ... Agile SW Entwicklung:

Wie System Simulation und Test Automation die agile Software Entwicklung beschleunigt

Ingo Nickles Field Application Engineer

Vector Software, Inc. www.vectorcast.com

ingo.nickles@vectorcast.com

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

> > > > System Simulation

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.

Agiles Testen im Vergleich zum Wasserfall-Testen

Maintenance

Design

Anforderung

Implemen-tierung

Maintenance

Design

Anforderung

Implemen-tierung

Produktentwicklung häufig parallel für und

Software

Hardware

Testen der Software setzt Verfügbarkeit der Hardware voraus

Feste Termine

Schwarzer Peter Spiel

Trennung Entwickler<->Tester

Agil nicht möglich

Agile SW Entwicklung: Scrum

Produkt Backlog

Sprint Backlog

Mehrere Test- und Demo-Phasen

Koordination mit HW schwierig bis unmöglich

Simulation macht Scrum erst möglich

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)

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

> > > > Testen - Grundlagen

> 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

> Gefordert von Standards > MISRA, MISRA C++

> IEC 62304

> 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

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

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

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

> > > > Automatische Testfall Erstellung

> 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

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

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

> 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

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

> > > > Agile und Testen

> 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

Testen und Agilität

Test Automation am Beispiel: Scrum

> 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

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

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

Alle Testfälle

ausführen

Code Änderung

Alle Testfälle ausführen

Re-Design Step 1..n

> > > > Projekt Testumgebung und Change Based Testing (CBT)

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

Test Daten IN / OUT

Reports

PASS/FAIL

Code Coverage 100%

IN: - Funktion Parameter - Globals - Stub Returns OUT: - Funktion Returns - Globals - Stub Parameter

Test Daten

Test Umgebungen in einem Projekt

Source code

1 Modul Test Umgebung pro File

Mehrerer Integrations Test Umgebungen mit 2 oder mehr Files

1 oder mehr System Test Umgebungen

Testen verschiedener Varianten

Source code

> 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

Software Änderungsprozess in der Praxis

Source code

> 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

Was ist Change Based Testing?

Source code

> Ä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.

Welche Testumgebungen müssen neu gebildet werden?

Modul Test Umgebung

Integrations Test Umgebung

System Test Umgebung Source code

Welche Testfälle müssen ausgeführt werden?

Modul Test Umgebung

Welche Testfälle müssen ausgeführt werden?

Modul Test Umgebung

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

> 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

Beilspiel einer CBT Test-Umgebung: CBT Report

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: info@vectorcast.com

EMEA Golden Cross House 8 Duncannon Street London WC2N 4JF, UK T: +44 203 603 0120 F: +44 207 022 1651 E: info@vectorcast.com

Deutschland St. Töniser Str 2a 47906 Kempen Deutschland T: +49 2152 8088808 F: +49 2152 8088888 E: info@vectorcast.com

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: info@apac.vectorcast.com

v e c t o r c a s t . c o m

Wie System Simulation und Test Automation die agile ... · die agile Software Entwicklung beschleunigt Ingo Nickles Field Application Engineer Vector Software, Inc. ... Agile SW Entwicklung:

Documents

KEGON agile entwicklung in großen Organisationen

Henning Wolf, Stefan Roock Agile Software- entwicklung ·.....

Hardware-Entwicklung noch einmal neu gedacht: Neue...

Software-Entwicklung Lean & Agile in der Bedag › ... ›.....

Softwareprojekte im Informatikstudium -...

Software-Entwicklung Lean & Agile in der Bedag · Agile"...

Agile Entwicklung für iOS und Android - xpdays.de · ©...

3. Swiss Agile Study - Fachhochschule...

Agile Software Entwicklung mit Scrum

Beyond Agile - Antifragilität in der Software-Entwicklung -...

Microservices – die Architektur für Agile-Entwicklung?

Agile Software Entwicklung mit - files.ifi.uzh.ch · Agile....

UX und agile Entwicklung - eine Aufgabe für das ganze Team

Status Quo...

Bitcoins und Blockchains - tcbe.ch · ICT-Beschaffungen:...

Brand Development Expert, Liz Nickles