Software-Entwicklung
FDA empfiehlt automatisierte Tools für den Software-Test
In ihren »General Principles of Software Validation« empfiehlt FDA die Automatisierung von Testaktivitäten über den gesamten Software-Entwicklungsprozess hinweg. Welche Anforderungen stellt die FDA an Softwaretests, welche Tests sollten durchgeführt werden und wie können da Testwerkzeuge helfen?
Unter den »General Principles of Software Validation« (GPoSV) fasst die US-amerikanische Food and Drug Administration (FDA) ihre Empfehlungen für den Testprozess und dessen Ausführung zusammen. Im Abschnitt 5.2.5 »Testing by the Software Developer« erläutert das Dokument die drei FDA-Prüfstufen für die Entwicklung:
- Tests auf Modul- oder Komponenten-Ebene mit dem Ziel, dass sich Software-Abschnitte in geeigneter Qualität für die Integration in das Software-Endprodukt bereitstellen lassen.
- Tests auf Integrationsebene mit dem Ziel, dass die Übertragung von Daten und Steuerungsinformationen korrekt über die internen und externen Schnittstellen eines Programms erfolgt.
- Tests auf Systemebene zum Nachweis, dass der gesamte spezifizierte Funktionsumfang implementiert wurde, und dass das Software-Produkt vertrauenswürdig ist.
Aber warum sollte ein europäischer Medizintechnik-Hersteller sich für die FDA und deren GPoSV interessieren? Es gibt doch die europäische Direktive 93/42/EEC, Anhang I, Abschnitt 12.1a für medizinische Geräte: »Bei Geräten, die Software enthalten und bei medizintechnischer Software muss diese Software entsprechend dem letzten Stand der Technik überprüft werden; dabei müssen die Prinzipien des Entwicklungs-Lebenszyklus, des Risikomanagements, der Validierung und der Verifizierung beachtet werden.«
Man könnte also die Auffassung vertreten, dass die DIN EN 62304 neben den GPoSV bereits den letzten Stand der Technik zur Ausführung einer Softwarevalidierung beschreibt. Andererseits vertreiben viele Hersteller ihre Produkte auf internationalen Märkten, auf denen die Einhaltung der FDA-Bestimmungen erforderlich ist. Und wenn ein Hersteller schließlich seine Produkte auf dem US-amerikanischen Markt verkaufen will, dann muss er seine Produkte ohnehin in Übereinstimmung mit den GPoSV-Richtlinien entwickeln.
Die FDA empfiehlt beim Software-Testprozess, dass »dieser unabhängig von der Codeerstellung sein sollte« und dass »der Prüfer andere Werkzeuge benutzen sollten als Code-Ersteller«. Dies legt nahe, dass Softwareentwickler bei der Codeerstellung keine Modultest-Frameworks wie CppUnit oder JUnit verwenden sollten. Andererseits fordern die GPoSV-Empfehlungen, dass »Testfälle so frühzeitig wie möglich im Software-Entwicklungsprozess erstellt werden sollten«.
Einsatz eines automatisierten Testwerkzeugs
Eine mögliche Lösung, um diese FDA-Empfehlungen einzuhalten, ist der Einsatz eines automatisierten Testwerkzeugs, das die Testroutinen nach dem TDD-Konzept (Test Driven Development) erstellt.
Bild 1 zeigt die prinzipielle Struktur einer automatisch generierten Testbench für den Modul- oder Integrationstest. Werkzeuge zur Test-Automatisierung können automatisch Dummy-Funktionen (Stubs) erzeugen.
In einem TDD-Prozess ist dies eine wichtige Funktion, mit der sich Testfälle erstellen und ausführen lassen, bevor der Code bereitsteht.
Einige Test-Automatisierungswerkzeuge können auch Modul- und Integrationstests auf einen Simulator, Emulator oder dem Embedded-Zielsystem ausführen.
Für die Unterstützung der verschiedenen Hardware-Anforderungen verwendet man eine »Runtime Support Package« (RSP) (Bild 2).
Weiterhin fordern die GPoSV-Empfehlungen, dass »Softwaretests mit einen Test auf Modulebene beginnen und mit Tests auf Systemebene abgeschlossen werden« und »der Test eines Softwareprodukts in Modul-, Integrations- und Systemtests aufgegliedert sein sollte«.
- FDA empfiehlt automatisierte Tools für den Software-Test
- Testwerkzeuge
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
