Testautomatisierung. Schritthalten mit agiler Software-Entwicklung. Matthias Hölzer-Klüpfel

Transkript

1 Testautomatisierung Schritthalten mit agiler Software-Entwicklung Matthias Hölzer-Klüpfel

2 Aufgabenstellung Entwicklung eines innovativen Medizinprodukts in einem Startup-Unternehmen bis zur CE-Kennzeichnung

3 Entwicklungsprozess (extern)

4 Software-Qualitätssicherung Confidence, Design-zentriert Statische Codeanalyse Systematische Code-Reviews Automatisierte Unit-Tests Evidence, Requirements-zentriert Blackbox-Tests Software-Systemtests

5 Software-Qualitätssicherung Confidence, Design-zentriert Statische Codeanalyse Systematische Code-Reviews Automatisierte Unit-Tests Evidence, Requirements-zentriert Whitebox-Tests Software-Systemtests

6 Systemarchitektur User Interface Supervisor Controller Hardware

7 Manueller Software-Systemtest Input-Simulation: Widerstandsdekaden Simulationssoftware Teile der Hardware Datenerfassung: Logic-Analyser Serieller Logger

8 Problematik Hohe Fehleranfälligkeit Software-Modifikationen notwendig Manuelle Auswertung unsicher Schwer nachprüfbar Aufwand: 18 Personenmonate!

9 Geänderte Rahmenbedingungen Entwicklung wird intern übernommen Software-Entwicklung wird agiler Software-Systemtest wird intern durchgeführt Ziel für die Durchlaufzeit: unter 1 Woche Software-Systemtest muss automatisiert werden

10 Anforderungen Testautomatisierung Vollständig automatisch: Testdurchführung Testauswertung Testskripte: können durch Tester entwickelt werden spiegeln die semantische Tiefe der Requirements Testausführung: parallelisierbar in weniger als einer Woche Test der unveränderten Produktsoftware Entwicklung nach IEC 62304

11 System-under-Test User Interface Supervisor Controller Hardware

12 Testsystem IO-Simulator Supervisor Controller Testtreiber IO-Simulator

13 Testsystem Testskript (XML) Testtreiber (PC, Windows, C#) Testreport (XML) USB IO-Simulator (Hardware, μc) physikalisch, 1:1 System-under-Test

14 Testskript-Anweisungen Anweisung set wait send expect monitor delay repeat verify Funktion Ändert eine simulierte Größe. Erwartet den Eintritt eines beobachteten Zustands. Schickt eine serielle Nachricht. Erwartet die Ankunft einer seriellen Nachricht. Überwacht den Systemzustand nebenläufig. Wartet ab. Wiederholt Anweisungen für eine Anzahl oder eine Zeit. Zeigt einen Trace zu einer Anforderung.

15 Beispiel: Testskript REQ1234: Test der Alarm LED Nach dem POST blinkt die Alarm LED 5 mal mit 1Hz und 50% Einschaltdauer.

16 Testspezifikation

17 Testausführung ca. 400 Testskripte Abdeckung der Software-Requirements: >80% ca. 100 Stunden Laufzeit 6 Teststände (4 produktiv) Testdurchlaufszeit: 2 Tage

18 Orchestrierung Verwendung des Continuous Integration Systems Testskripte stehen unter Versionskontrolle Automatisierter Testlauf Ablage der Testergebnisse im Versionskontrollsystem verwendetes Werkzeug: Jenkins

19 Test Report

20 Lessons Learned

21 Semantik der Skriptsprache Passe die Skriptsprache an die Domäne an! beschleunigt das Schreiben der Testskripte erlaubt ein breites Review ermöglicht, in den Skripten zu dokumentieren

22 Modifikation des SUT Modifiziere das System-under-Test wenn nötig! möglichst rein digitale Schnittstellen Override-Signale: Supervisor Controller Abgriff von Signalen zu Testzwecken

23 Modifikation des SUT Modifiziere das System-under-Test wenn nötig! möglichst rein digitale Schnittstellen Disable- und Override-Signale: Supervisor Controller Override Abgriff von Signalen zu Testzwecken Disable

24 Testhardware Baue genügend Testhardware auf! 2 Teststände hätten für das Zeitziel ausgereicht, aber: Testhardware muss auch überarbeitet werden Die Elektroniker nutzen die System (jetzt) auch Die Entwicklungszeit dominiert, man sollte nicht auf Teststände warten müssen

25 TODO-Konzept Plane für unvollständige Zwischenzustände! Die getestete Software hat Fehler Die Skripte können nicht einfach aufgeben Workarounds müssen gemacht und verfolgt werden <todo>-kommando mit Issue-Nummer

26 Software-Deployment Automatisiere auch das Flashen der Controller! 3 Controller, 6 Teststände = 18 Flash-Operationen Falsches Flashen kann unser Board zerstören Erlaubt die Integration in den Nightly Build (Das hätte uns vorher jemand sagen müssen!)

27 Spannungsversorgung Do not drive power into an unpowerd board! Testsystem muss das SUT powercyclen können Wenn das SUT keine Versorgungsspannung, darf keine Spannung durch das Testsystem injiziert werden Lösung: Tristate-Buffer

28 Abschließende Beobachtungen Fehler sind sehr viel einfacher zu reproduzieren Phantomfehler sind sehr selten gewesen die Arbeit wird spannender, wenn die Software- Entwicklung eingeholt wurde Der Zeitaufwand hat sich schon vor der formalen Testphase gelohnt

29 Fazit Agile Software-Entwicklungsprojekte sind schwer mit langwierigen manuellen Tests in Einklang zu bringen Vor allem der requirements-basierte Software-Systemtest kann ein Entwicklungsprojekt vor Herausforderungen stellen Konsequente Testautomatisierung erlaubt es, die Durchlaufzeit im Zaum zu halten Dazu ist es sinnvoll, Aufwände vorzuziehen und parallel zur Entwicklungsphase ein Testsystem zu projektieren Durch ein maßgeschneidertest System aus Testskript-Sprache und Testhardware kann sehr flexibel auf Änderungen in der Software, die getestet wird, reagiert werden

30 Kontakt MATTHIAS HÖLZER-KLÜPFEL DIPLOM-PHYSIKER, M.SC. post Zweite Felsengasse Würzburg tel fax mobil mail web matthias@hoelzer-kluepfel.de