Softwaretests. automatisiert. Software für Medizinprodukte ist nicht nur komplex, MED Informatik Softwaretests

Transkript

1 2013 Carl Hanser Verlag, München Nicht zur Verwendung in Intranet- Internet-Angeboten sowie elektronischen Verteilern. Um die Softwareentwicklung für Medizingeräte effizienter zu machen, geht die Tendenz hin zur Testautomatisierung. Die auto matisiert verifizierbare Spezifikation ist das finale Ziel. Softwaretests automatisieren 1 Philips Healthcare Diagnostic X-Ray hat mit FitNesse die Verifikationstests automatisiert Software für Medizinprodukte ist nicht nur komplex, sondern muss auch hohe juristische regulatorische Anforderungen erfüllen. Es gilt, das Medizinproduktegesetz (MPG) einzuhalten, eine CE-Zertifizierung zu erlangen, teilweise klinische Tests vor der Markteinführung durchzuführen Normen einzuhalten wie: + + DIN EN ISO 14971: : Medizinprodukte Anwendung des Risikomanagements auf Medizinprodukte + + DIN EN :2006 (3. Edition): Medizinische elektrische Geräte Teil DIN EN 62304:2006: Medizingeräte- Software Soft ware-lebenszyklus- Prozesse Kontakt Stefan Trapp Consulting Ingenieurbüro Hamburg Tel. +49 (0) Mit der DIN EN :2006 3rd Edition wurde die Bedeutung des Risikomanagements erheblich gestärkt. Das Risikomanagement nach DIN EN ISO ist damit ein wesentlicher Bestandteil des Sicherheitskonzepts für Medizingeräte. Die DIN EN 62304:2006 definiert den Entwicklungsprozess (Bild 2) für Software-Medizinprodukte. Neben dem Software-Entwicklungsprozess werden hier die obligatorischen entwicklungs begleitenden Prozesse Software-Risikomanagement, Software-Konfigurationsmanagement Software-Problemlösung definiert. Eine zentrale Anforderung der DIN EN ist die Dokumentation Rück- Bild: Philips (Royal Philips N.V.) 38

2 2013 Carl Hanser Verlag, München Nicht zur Verwendung in Intranet- Internet-Angeboten sowie elektronischen Verteilern. verfolgbarkeit (Traceability), mit der sich nachvollziehen lässt, dass die System-/Softwareanforderungen erfüllt sind die in der Software implementierten risikoreduzierenden Maßnahmen (RRM) durch den System-/Soft waretest abgedeckt werden. Die RRM sind ein Ergebnis des in Bild 2 dargestellten Risikomanagements. Aus den Erfordernissen der DIN EN ergibt sich erstens, dass der Entwicklungsprozess für medizinische Software zwingend den Risikomanagementprozess beinhalten muss. Zweitens muss jede RRM in der Software mit mindestens einem Testfall verknüpft sein, damit sichergestellt ist, dass die Maßnahme korrekt implementiert wurde. Dies gilt für alle Software-Medizinprodukte unabhängig davon, welcher Klasse sie zugeordnet werden. Softwaretest testgetriebene Entwicklung Systementwicklung (inklusive Risikomanagement) Software-Risikomanagement Kenbedürfnisse Entwicklungsplanung Anforderungsanalyse Architekturentwurf Detailentwurf Implementation Verifikation Tests sichern die Softwarequalität ermöglichen somit die spätere möglichst fehlerfreie Inbetriebnahme der Software. Fehlerfreiheit ist insbesondere dann wichtig, wenn Menschenleben ge fährdet sind. Allerdings wird durch Tests nicht die Fehlerfreiheit einer Software nachgewiesen, sondern es ist nur eine Aussage über die ausgeführten Testfälle möglich. Der Testaufwand hängt von der Testbarkeit des zu prüfenden Produkts ab. Neben anderen qualitätsverbessernden Maßnahmen sind daher eine verbesserte Testbarkeit der Software die Testautomatisierung wichtige Elemente, um die Effizienz bei der Softwareentwicklung zu erhöhen. Soft waretests können in dynamische statische Verfahren eingeteilt werden. Im Fokus der Testautomatisierung stehen die dynamischen Tests, die auf der Ausführung des zu testenden Programmteils stests Software-Konfigurationsmanagement Software-Problemlösung Systemtest beruhen. Für einen solchen Test(-fall) werden die Eingaben die erwarteten Ausgaben spezifiziert. Letztere werden nach dem Test mit dem tatsächlichen Resultat verglichen. Außer dem wird festgelegt, wie das System initialisiert werden muss, um den Test durchführen zu können. Dynamische Tests lassen sich in verschiedene Teststufen einteilen, die sich an den Stufen des V-Modells orientieren: + + Unit-Tests + + stests + + Systemtest + + Akzeptanztests erfüllte Kenbedürfnisse Freigabe 2 Software-Entwicklungsprozess gemäß DIN EN 62304:2006 Unit-Tests werden meist von Soft wareentwicklern geschrieben mithilfe spezieller Entwicklungstools (xunit, xmocks Tools zur kontinuierlichen ) automatisiert aus geführt. Getestet wird die Funktionalität einzelner, abgrenz barer Teile der Software (Klassen, Units oder Module), mit dem Ziel, die Lauffähigkeit nachzuweisen (Teil-)Ergebnisse zu prüfen. stests prüfen die Zusammenarbeit der voneinander abhängigen Komponenten. Sie können mit den gleichen Tools wie die Unit-Tests implementiert werden, sollen aber die Korrektheit der Komponentenschnittstellen der komponentenübergreifenden Abläufe nachweisen. Im Systemtest wird geprüft, ob das gesamte System die Spezifikation (funktionale nicht funktionale Anforderungen) erfüllt. Der Systemtest lässt sich beispielsweise mit Tools wie QF-Test für die grafische Benutzerschnittstelle eines Softwaresystems automatisieren. 39

3 2013 Carl Hanser Verlag, München Nicht zur Verwendung in Intranet- Internet-Angeboten sowie elektronischen Verteilern. Systemanforderungen risikoreduzierende Maßnahmen (RRM) Zuordnung/ Verfeinerung Software- komponenten- Anforderungen komponentenspezifische RRM Systemverifikation QF-Test, manuelle Tests, Dauerlauftests Software-Subsystem-Verifikation QF-Test, FitNesse, manuelle Tests Softwarekomponenten-Verifikation FitNesse Softwarekomponenten-Unit-Tests xunit, xmocks 3 Teststufen zugehörige Testmethoden -werkzeuge bei der Systemverifizierung Akzeptanztest mit FitNesse Akzeptanztests sind Tests einer gelieferten Software durch den Auftraggeber oder Ken. Neben kompletten Systemen können Akzeptanztests auch für Software-Artefakte mit eigenem Software-Releasezyklus eigener Anforderungsdefinition realisiert werden. Ein verbreitetes Open Source Tool für automatisierte Akzep tanztests ist FitNesse. Es basiert auf dem Framework for Integrated Test gestattet die browser basierte Defi nition von Testfällen in Form von Entscheidungs tabellen in einem Wiki. Für das Testfall-Wiki sind keine Programmier kenntnisse erforderlich. Daher kann es vom Anforderungs manage ment oder den Domä n en-experten erstellt werden. Es bildet im Idealfall die vollständige, ausführbare Spezi fika tion eines Software-Artefakts ab. Bei der testgetriebenen Entwicklung werden die automatisierten Testfälle vor dem Schreiben des Programmcodes entwickelt. Da die Funktionalität durch die ausführbaren Testfälle spezifiziert ist, ist eine gesonderte Anforderungsdefinition System Software-Subsystem Softwarekomponente im Prinzip überflüssig. Entwickler Ken erhalten hier früh Feedback über Probleme bei der Implementierung der Testausführung. Die umfassende Testbarkeit in frühen Entwicklungsphasen rückt damit näher. Testgetriebene Entwicklung setzt aber die kontinuierliche, das objekt orientierte Design Refactoring voraus. Bei der kontinuierlichen werden Code-Änderungen normalerweise täglich der Versionsverwaltung hinzugefügt. Anschließend wird das Gesamtsystem automatisch durch ein Tool für die Continuous neu gebaut getestet, um mögliche Probleme durch Änderungen sofort zu erkennen. Prinzipien des objektorientierten Designs wie Single-Responsibility-, Open-Closed-, Liskovsches Substitutions-, Interface- Segregation- oder Dependency-Inversion-Prinzip sollen die Wartbarkeit Testbarkeit verbessern damit die Qualität Lebensdauer der Software erhöhen. Abhängigkeiten sollen reduziert werden, oder anders ausgedrückt, Systemelemente sollen leichter isolierbar sein Komponenten, Klassen oder andere Software-Artefakte weniger komplex. Refactoring bezeichnet die manuelle oder auch die automatisierte Strukturänderung eines Softwaresystems, ohne die Funktiona lität oder die Schnittstellen nach außen zu verändern. Das soll die Lesbarkeit, Wartbarkeit Erweiter barkeit der Software verbessern. Automatisierte Tests dienen dabei als Regressionstests: Durch die Gesamtheit der Testfälle soll sichergestellt werden, dass trotz der Änderungen die implementierte Funktionalität intakt bleibt. 40

4 2013 Carl Hanser Verlag, München Nicht zur Verwendung in Intranet- Internet-Angeboten sowie elektronischen Verteilern. Philips Healthcare DXR hat eine Teststrategie für Röntgensysteme (Bild 1), die aus Hard- Software bestehen, implementiert. Grsätzlich werden hier Teststrategie bei Philips Healthcare DXR Domänen-Experten/ Anforderungsmanagement risikoreduzierende Maßnahmen aus dem Risikomanagement Textverarbeitung (z.b. MS Word) Wiki-Seiten Wiki-Text Testfall-Wiki FitNesse Browser manuell Aufruf (HTML/ XML/PDF) kontinuierliche (z.b. CruiseControl) manuell Aufruf automatische Einbettung in Dolkumentvorlage Konfiguration der kontinuierlichen Entwicklung Anforderungen Tests der Geschäftslogik in verständlichem Klartext zur Erfüllung der Nachweispflicht gemäß DIN EN Verifikations- Validationstests unter schieden. Während bei der Verifikation festgestellt wird, ob eine Software der Spezifikation entspricht (funktionales Testen), wird mittels Validation geprüft, ob eine Software den Benutzeranforderungen genügt. Der Fokus liegt im Folgenden auf der Verifikation (Bild 3). Basis für alle Verifikationstests sind die Systemanforderungen die aus dem Risikomanagement resultierenden RRM. Diese Anforderungen umfassen als Teilmenge auch die vom Softwaresubsystem zu erfüllenden Anforderungen. Da das Softwaresubsystem aus mehreren Komponenten besteht, werden die System anforderungen die RRM den Softwarekomponenten zugeordnet auf Komponentenebene verfeinert. Die Verifikation findet auf den Ebenen der Softwarekomponenten, des Softwaresubsystems des Gesamtsystems (Hard- Software) statt. Bei den Komponententests kann weiter zwischen Softwarekomponenten-Unittests Softwarekomponenten-Verifikation unterschieden werden. Auf SLIM Runners SLIM Executor Fixture- Aufrufe Textfixtures regelmäßige automatische Test- Ausführung im Rahmen der kontinuierlichen FitNesse besteht aus einem Webserver, einem Wiki einer Test En- Verifikations- Ergebnisbericht Nachvollziehbarkeit API- Aufrufe den Ebenen Soft ware-subsystem System werden neben automatisierten Tests mit FitNesse oder QF- Test weitere Testmethoden, zum Beispiel manuelle Tests Dauerlauftests, angewendet. Mit FitNesse soll die Verifikation automatisiert der Verifikations-Ergebnisbericht automatisch erzeugt werden, um die Nachweispflicht gemäß DIN EN zu erfüllen. Geplant ist es, zu einer automatisiert ausführbaren verifizierbaren Spezifikation zu gelangen, die die manuelle Durchführung Dokumentation der Verifikationstests überflüssig macht. Dies ist wie in diesem Fall bei Software mit regelmäßigen Updates Releases besonders interessant. Testsystem (SUT) Eigenentwicklung Standard-Tools u. Bibliotheken Dokumente (elektronisch/print) 4 Automatisierte Erzeugung von Verifikations-Ergebnisberichten mit FitNesse zur Erfüllung der Nachweispflicht gemäß DIN EN

5 2013 Carl Hanser Verlag, München Nicht zur Verwendung in Intranet- Internet-Angeboten sowie elektronischen Verteilern. gine (SLIM) (Bild 4). Die Anbindung der Testfälle an das zu testende System wird durch sogenannte Testfixtures realisiert. Das Wiki gestattet anschließend mit FitNesse der zugehörigen Test Engine SLIM die browserbasierte Ausführung der Tests. Die Test ergebnisse werden durch Ampelfarben auf den Wiki-Seiten angezeigt. Dieses Testergebnis lässt sich als PD- F-Dokument manuell in die Dokumentenvor lage des Verifikations-Ergebnisberichts der Softwarekomponente beziehungsweise des Softwaresubsystems einfügen, wodurch die regulatorischen Dokumentationsanforderungen erfüllt sind. Nur dieser geringe manuelle Aufwand ist bei einem Software Re lease zu leisten. Neben dieser manuellen Auslösung der automatisierten Verifikation zeigt Bild 4 zusätzlich die automatisierte Auslösung im Rahmen der kontinuierlichen. Mit dem Werkzeug zur kontinuierlichen wird in diesem Fall FitNesse regelmäßig gestartet. Bei einem Software Release wird das Test ergebnis durch das Continuous Tool zusätzlich automatisch in die Dokumentenvorlage des Verifikations-Ergebnisberichts eingefügt. Ungeachtet dieser Vorzüge der Quelloffenheit hat FitNesse auch Schwachpunkte: + + mangelnde Dokumentation + + einseitige Änderungen/Refactorings im Testfall-Wiki oder den Testfixtures lassen Tests fehlschlagen, da es keine Verknüpfung zwischen dem Wiki dem zugehörigen Testcode wie bei einer integrierten Entwicklungsumgebung (IDE) gibt + + keine Autovervollständigung (IntelliSense) bei der Bearbeitung der Wiki-Testfälle + + eingeschränktes Debugging Treiberpaket für Industriekameras Erweitert den Anwendungsbereich. Der Kamerahersteller IDS Imaging Development Systems bietet ein neues Treiberpaket für seine USB 2.0, USB 3.0 GigE Industriekameras an. Die Software Suite 4.30 steht auf der Website des Anbieters kostenlos zum Download bereit. Das Softwarepaket besitzt einige zusätzliche Features, unter anderem ist für die USB 3 ueye CP Kamera mit 4,2 Megapixel CMOSIS Sensor (UI-3370CP) jetzt ein getriggerter Zeilenmodus verfügbar. Diese Betriebsart erweitert den Anwendungsbereich der Flächenkamera mit USB 3.0-Anschluss. Jede einzelne Zeilenaufnahme lässt sich im getriggerten Modus mit einem Incrementaldecoder auslösen. Laut Hersteller sind bei der Flächenkamera im Gegensatz zur Zeilenkamera die Einrichtung einfacher die Systemkosten geringer. Die Treiberversion 4.30 ist WHQL-zertifiziert, das heißt sie erfüllt die Microsoft-Kriterien besitzt ein Windows-Logo sowie eine digitale Signatur. Die Software ist somit mit Windows kompatibel, was für den Benutzer mehr Sicherheit das Wegfallen von Warnmeldungen aus dem Betriebssystem bedeutet. Eine Linux-Version der Software wird es in Kürze geben. Auch für bereits installierte Kameras stehen die zusätzlichen Funktionen des Treiberpakets 4.30 nach einem Software-Update sofort zur Verfügung. Zur Produktseite des Herstellers mit: Der vorgestellte Ansatz, die Softwareverifikation bei Philips Healthcare DXR zu automatisieren, hat die Testaufwände erheblich reduziert, die Durchlaufzeit verkürzt die Zuverlässigkeit von Software Test verbessert. Nachdem bislang nur Testfälle für risiko reduzierende Maßnahmen automatisiert wurden, ist zum gegenwärtigen Zeitpunkt zwar ein wichtiges Etappenziel erreicht, bis zur vollständig auto matisiert ausführbaren verifizierbaren Spezifikation ist es aber noch ein weiter Weg. $ Stefan Trapp ist selbstständiger Ingenieur. stefan.trapp@stefan-trapp-consulting.de Quicklink Mit unserem Quicklink-Service gelangen Sie sofort zur Herstellerinformation. Einfach den Link im Browser eingeben. 42