Testen von Software für Medizinprodukte: Standards, Strategien und Tools

Die Entwicklung von Software für Medizinprodukte erfordert rigorose Tests, um die Patientensicherheit und die Einhaltung gesetzlicher Vorschriften zu gewährleisten. Solche Software läuft häufig auf Hardware mit Echtzeitanforderungen und in lebensbedrohlichen Situationen, was umfassende Tests unumgänglich macht.

Bei Scythe Studio sind wir auf eingebettete medizinische Anwendungen mit Qt/C++ spezialisiert und verfolgen beim Testen eine fachkundige, systematische Methodik. Dieser Artikel beschreibt unsere technische Sichtweise auf das Testen und behandelt:

 

• Branchenstandards (IEC 62304, ISO 13485, FDA-Richtlinien),
• Testmethoden (Unit-, Integrations-, System-, Verifikations- & Validierungstests),
• Tools für Qt/C++ (Squish, Google Test, CppUnit, statische Analyse),
• und wie wir Rückverfolgbarkeit, Risiken und Dokumentation im gesamten Prozess verwalten.

In diesem Artikel teilen wir praktische Einblicke aus realen Projekten mit medizinischen Geräten, um bewährte Verfahren zur Qualitätssicherung medizinischer Software zu veranschaulichen – alles im Rahmen dieses stark regulierten Bereichs.

In zukünftigen Artikeln werden wir vermutlich darauf eingehen, wie sich all diese Konzepte zu einem funktionierenden und möglicherweise automatisierten Testprozess zusammenführen lassen.

 

Regulatorische Standards und Anforderungen für das Testen medizinischer Software

Manche Menschen verfluchen möglicherweise die Regulierungsbehörden für ihre hohen Anforderungen an die Entwicklung medizinischer Software. In der Praxis begrüße ich das sogar, denn in der Welt der Softwareentwicklung wird viel über Qualität und Tests gesprochen – und zumindest hier sind Softwaretests und Qualitätssicherung keine leeren Worte.

 

Sehen wir uns an, mit welchen regulatorischen Anforderungen wir es zu tun haben.

 

FDA-Vorschriften

Das Testen von Software für Medizinprodukte unterliegt strengen internationalen Normen und den Vorschriften der US-amerikanischen FDA, die festlegen, wie Tests geplant, durchgeführt und dokumentiert werden müssen. Die Quality System Regulation der FDA (21 CFR Part 820) verpflichtet Hersteller dazu, Verfahren zur Validierung des Geräteentwurfs zu etablieren und aufrechtzuerhalten, einschließlich der Softwarevalidierung und Risikoanalyse.

Die Einhaltung der FDA-Vorschriften stellt sicher, dass Tests nachvollziehbar, wiederholbar und auf die Ziele der Patientensicherheit abgestimmt sind. Darüber hinaus betont die FDA in ihren Richtlinien die Bedeutung der Dokumentation darüber, wie sich Software sowohl unter normalen als auch unter Fehlerbedingungen verhält, was die Notwendigkeit umfassender und risikobasierter Teststrategien unterstreicht.

 

IEC 62304

IEC 62304 ist die internationale Norm für den Lebenszyklus von Software für Medizinprodukte, die die Entwicklung vom Planungs- bis zum Wartungsstadium abdeckt. Sie klassifiziert die Softwaresicherheit nach Risikoklassen (Klasse A/B/C) und verlangt Tests während des gesamten Entwicklungszyklus, um zu überprüfen, ob die Software ihren vorgesehenen Zweck und die Designanforderungen erfüllt. Der Umfang der Tests hängt dabei weitgehend von der Gerätekategorie ab.

In der Praxis verlangt IEC 62304 testgetriebene Entwicklung, Funktionstests und risikobasierte Tests als Teil der Verifikationsstrategie. Die Norm fordert außerdem eine abschließende Validierung der Software in der tatsächlichen Betriebsumgebung, um sicherzustellen, dass die Gerätesoftware ihren vorgesehenen Zweck sicher erfüllt.

Kurz gesagt: Risikomanagement und umfassende Tests sind unter IEC 62304 entscheidend, insbesondere bei Hochrisiko-Systemen der Klasse C.

 

ISO 13485

ISO 13485 ist die internationale Norm für Qualitätsmanagementsysteme (QMS) für Software medizinischer Geräte, die sich auch auf das Testen auswirkt. Hersteller medizinischer Geräte, die ISO 13485 implementieren, müssen formale Designkontrollen einführen und sicherstellen, dass Prozesse wie Verifikation und Validierung geplant und dokumentiert werden.

ISO ist zwar keine gesetzliche Vorschrift, aber ein angestrebter Standard für Entwickler medizinischer Geräte. Sie spielt eine Schlüsselrolle im Testprozessmanagement, indem sie eine umfassende Dokumentation, standardisierte Abläufe und kontinuierliche Verbesserungen sicherstellt.

 

Da wir bei Scythe den Standard ISO 13485:2016 (sowie das vergleichbare Qualitätssystem der FDA) implementiert haben, pflegen wir detaillierte Testpläne, Testverfahren und -ergebnisse als Teil der Design History File, was vollständige Transparenz und Rückverfolgbarkeit der Tests ermöglicht.

Jede Entscheidung – von der Toolauswahl bis zur Testabdeckung – muss gemäß dem QMS gerechtfertigt und dokumentiert werden. Das bedeutet, dass unsere Testaktivitäten nicht nur technisch fundiert, sondern auch auditfähig sind – mit Belegen dafür, dass Anforderungen verifiziert und Abweichungen behandelt wurden.

 

Testmethoden für eingebettete medizinische Software

Wir verwenden eine mehrschichtige Teststrategie, um medizinische Gerätesoftware systematisch zu verifizieren – von Low-Level-Code-Einheiten bis hin zum vollständigen System. Softwaretests wären ohne automatisierte und manuelle Testmethoden nicht möglich.

Die wichtigsten Testmethoden sind:

 

• Unit-Tests,
• Integrationstests,
• Systemtests,
• usa
• bekannte manuelle Tests.

 

Jede Ebene zielt auf unterschiedliche Fehlertypen ab und orientiert sich am Entwicklungsprozess: Während Low-Level-Tests das detaillierte Design verifizieren, validieren Tests auf höherer Ebene die Software gegenüber den Benutzeranforderungen. Im Folgenden beschreiben wir jede Testebene – mit Ausnahme des manuellen Testprozesses – und wie sie im Kontext medizinischer Gerätesoftware angewendet wird:

 

Unit-Tests

Bei Unit-Tests konzentrieren wir uns auf die kleinsten Softwarekomponenten – einzelne Funktionen, Klassen oder Module – um sicherzustellen, dass sie isoliert korrekt funktionieren. Wir simulieren oder mocken Hardwarekomponenten oder externe Dienste, um deterministische Off-Target-Tests durchzuführen.

Eine zuverlässige Leistung auf Einzelebene ist entscheidend, da selbst kleine Fehler wie Rechenfehler die Patientensicherheit beeinträchtigen können. Unit-Tests helfen uns auch dabei, Kodierungsstandards einzuhalten und potenzielle Probleme frühzeitig mit statischen Analysetools zu erkennen, z. B. Pufferüberläufe.

Ziel des Unit-Test-Prozesses ist es sicherzustellen, dass jede einzelne Funktion der Gerätesoftware ihre Rolle wie erwartet erfüllt.

 

Beispiel

Nehmen wir ein einfaches Beispiel: Beim Testen einer Infusionspumpe prüfen wir beispielsweise die Genauigkeit des Dosisberechnungsalgorithmus.

 

 

Integrationstests

Ein ordnungsgemäßer Test medizinischer Geräte umfasst die Sicherstellung, dass sich separate Geräte oder Komponenten eines Systems stabil miteinander verhalten. Diese Tests führen wir in der Regel auf Zielhardware oder Simulatoren durch, um Probleme mit Speicherbeschränkungen oder Task-Scheduling aufzudecken.

In der Praxis der medizinischen Softwareentwicklung mit Qt und C++ umfassen Integrationstests häufig die Überprüfung, ob Qt-Signale und -Slots korrekt verbunden sind und dass Threads ohne Deadlocks funktionieren, um das System auf umfassende Systemtests vorzubereiten.

 

Beispiel

In einer Qt-basierten mobilen App, die mit einem Glukometer kommuniziert, sollte ein Mechanismus implementiert werden, der die Kommunikation und das Timing zwischen diesen beiden Elementen testet. Bei Geräten mit höherem Risiko sollten zudem Leistungstests durchgeführt werden.

 

 

Systemtests

Bei Systemtests bewerten wir die vollständig integrierte Software und Hardware anhand aller definierten funktionalen, leistungsbezogenen und sicherheitsrelevanten Anforderungen in realistischen Nutzungsszenarien. In dieser Phase wird die Software als Black Box behandelt und ihr externes Verhalten überprüft.

Wir simulieren klinische Arbeitsabläufe und Szenarien wie Patientenüberwachung sowie Leistungs- (Reaktionszeit) und Fehlertests. Wir nutzen intensiv automatisierte Regressionstests mit Tools wie Squish, um die Softwarestabilität nach Änderungen zu überprüfen.

Man muss sich stets bewusst sein, dass ein ordnungsgemäßer Testprozess ein Teil des Risikomanagements ist. Nur so lässt sich Patientensicherheit gewährleisten. Das Testen medizinischer Geräte bedeutet Risikominderung.

 

Beispiel

Systemtests an einem MRT-Gerät beinhalten das gleichzeitige Ausführen der GUI, der Steuerungssoftware und der Bildgebungsalgorithmen, um Genauigkeit und Einhaltung von Sicherheitsanforderungen zu gewährleisten.

 

Tools und Frameworks für das Testen medizinischer Gerätesoftware

Wir verwenden ein Set an Testtools und Frameworks, die auf die Entwicklung mit C++ und Qt abgestimmt sind, um die oben genannten Methoden effizient und zuverlässig umzusetzen. Die richtigen Tools helfen uns, Tests zu automatisieren, Kodierungsstandards durchzusetzen und Verifikationsnachweise zu sammeln.

Im Folgenden stellen wir einige der Tools vor, die wir verwenden, und zeigen, wie sie in unseren Qt/C++-Testworkflow für medizinische Software passen:

 

1. Unit-Test-Frameworks (C++)

Für das Low-Level-Testen unseres C++-Codes verwenden wir Frameworks wie:

 

• QTest
• Google Test,
• CppUnit
• und gelegentlich andere Testframeworks, je nach Projekt.

Google Test (gtest) eignet sich besonders gut für eingebettete Systeme, da es moderne C++-Funktionen unterstützt und detaillierte Testergebnisse liefert. Wir konfigurieren es häufig so, dass es JUnit-XML-Ergebnisse ausgibt, die in CI-Systeme integriert werden können.

In Legacy-Projekten stoßen wir auf CppUnit, ein weiteres Framework im xUnit-Stil. Diese Tools unterstützen Test-Driven Development (TDD) und ermöglichen Tests auf PCs oder direkt auf eingebetteter Hardware via Cross-Compilation – so stellen wir sicher, dass unsere Logik zuverlässig ist und regressionsgetestet wird.

Medizinische Systeme der höchsten Klasse (C laut IEC 62304 oder III gemäß FDA bzw. MDR) erfordern eine Testabdeckung von 100 %.

 

Messen der Testabdeckung

Wenn du Tools suchst, mit denen du die Testabdeckung von Unit-Tests messen kannst, solltest du dir gcov anschauen – ein kostenloses Open-Source-Tool, das analysiert, ob ein Programm jede Codezeile ausführt. Es funktioniert nur mit dem GCC-Compiler, d. h. es ist hauptsächlich für Linux-basierte medizinische Geräte geeignet.

Es gibt auch kostenpflichtige Optionen, die du in deinem Softwareentwicklungsprozess einsetzen kannst – z. B. Coco, das Teil des Qt-Angebots zur Qualitätssicherung ist.

 

 

2. GUI- und Integrationstest-Tools

Das Testen der GUI eingebetteter Qt-Anwendungen ist anspruchsvoll, deshalb verwenden wir Squish, ein Automatisierungstool für Qt-Oberflächen. Squish automatisiert Benutzerinteraktionen (Touch, Klicks, Tastatureingaben) und überprüft Reaktionen der Benutzeroberfläche – auch aus der Ferne auf eingebetteten Geräten.

Wir schreiben Skripte in Python, um Benutzerworkflows zu simulieren und manuelle Tests zu automatisieren. Squish unterstützt die für Normen wie IEC 62304 erforderlichen Tests und ist besonders hilfreich, da GUI-Tests oft auch Integrationstests sind – schließlich ruft die Benutzeroberfläche Funktionen im Hintergrund auf.

Für erweiterte Integrationstests kombinieren wir Squish mit anderen Tools oder schreiben eigene Testharnesses.

 

 

3. Statische Analyse und Codequalitäts-Tools

Statische Analyse trägt zur Qualitätssicherung bei, indem sie z. B. aufdeckt:

• Speicherlecks,
• Pufferüberläufe
• oder Verstöße gegen Standards bereits in frühen Entwicklungsphasen.

Tools wie qmllint und Clang-Tidy kommen in den meisten unserer Embedded-C++-Projekte zum Einsatz. Coverity erkennt Probleme wie Nullzeigerzugriffe und Probleme mit Nebenläufigkeit, und es erzwingt Standards wie MISRA C++.

Die Axivion Suite, zertifiziert für IEC 62304 Klasse C, liefert zusätzliche Verifikationsmöglichkeiten. Durch die Integration der statischen Analyse in unsere Build-Pipelines halten wir hohe Codequalität aufrecht und verhindern teure Fehler in späten Phasen. Außerdem entstehen so dokumentierte Nachweise für die Verifikation.

Für leistungsrelevanten eingebetteten Code verwenden wir Profiler (z. B. Valgrind/Callgrind oder ARM-spezifische Werkzeuge), um Zeitvorgaben zu überprüfen – als Ergänzung zu den Funktionstests.

 

 

4. Continuous Integration (CI) und Testmanagement

Automatisierungsserver und CI/CD-Pipelines (z. B. Jenkins, GitLab CI, GitHub Actions) verbinden unsere Testtools miteinander und liefern nach jedem Commit Feedback zu Testergebnissen.

Was wir tun, ist das Einrichten einer Testumgebung in Docker-Containern, sodass die Testumgebung schnell auf anderen Geräten eingerichtet werden kann – ohne stundenlang alle Abhängigkeiten manuell installieren zu müssen.

Eingebettete Zielsysteme verwenden Hardware-in-the-Loop- oder Simulationsumgebungen, die in CI integriert sind, sodass Builds realistisch validiert werden. CI stellt sicher, dass ein konsistenter, rigoroser Testprozess als Voraussetzung für die Einhaltung gesetzlicher Vorgaben eingehalten wird.

 

Rückverfolgbarkeit, Risikomanagement und Dokumentation

Das Testen medizinischer Gerätesoftware bedeutet nicht nur, Tests durchzuführen – es geht genauso darum, Abdeckung und Konformität nachzuweisen. Da dies eine regulatorische Anforderung ist, betreiben wir strikte Rückverfolgbarkeit, Risikomanagement und Dokumentation, um sicherzustellen, dass jede Anforderung und jedes Risiko durch einen Test abgedeckt ist – mit einem dokumentierten Nachweis.

 

Anforderungsrückverfolgbarkeit

Für jede Softwareanforderung (funktional, Leistung, Sicherheit) gibt es mindestens einen entsprechenden Testfall. Eine Rückverfolgbarkeitsmatrix verknüpft Anforderungen, Designelemente, Tests und Ergebnisse – entweder in einem Anforderungstool oder in einem Dokument. Sie ermöglicht die Rückverfolgung von Anforderungen zu Tests und umgekehrt.

Dies stellt eine vollständige Testabdeckung sicher und dient bei regulatorischen Audits oder FDA-Einreichungen als Nachweis für die Verifikation. Gefährdungsbezogene Anforderungen aus der Risikoanalyse (ISO 14971) werden gesondert in einer Hazard Traceability Matrix erfasst.

 

Risikobasiertes Testen

Wir testen risikoorientiert nach den Praktiken gemäß ISO 14971. Funktionen mit hohem Risiko werden frühzeitig und umfassend getestet – einschließlich normaler, Rand- und Fehlerszenarien.

Eine dokumentierte Begründung stimmt den Testumfang mit dem Risikoniveau ab und unterscheidet klar zwischen kritischen und kosmetischen Funktionen. Jede softwarebezogene Risikominderung ist einer Verifikationsaktivität zugeordnet, dokumentiert in Rückverfolgbarkeitsmatrizen oder Risikotabellen.

 

Beispiel

Bei kritischen Dosisberechnungen werden umfassende Tests durchgeführt. Risikokontrollmechanismen (Alarme, Redundanzen) werden gemäß den Richtlinien von IEC 62304 durch Fehlersimulation getestet.

 

 

Dokumentation und Nachweispflicht

Unsere Tests erzeugen eine große Menge an Dokumentation, die durch ISO 13485 und die FDA-Vorschriften gefordert wird. Zu den wichtigsten Dokumenten gehören Testpläne, detaillierte Testprotokolle und Testberichte mit objektiven Nachweisen (z. B. Logs, Screenshots, Datenprotokolle) – diese fließen in der Regel in die finalen Unterlagen ein, die an Regulierungsbehörden übermittelt werden.

Wir verbessern die Testqualität durch Versionskontrolle, Peer-Reviews und automatisierte Testscripte. Auditoren prüfen diese Dokumente sowie Rückverfolgbarkeitsmatrizen zur Verifikation der Konformität – daher behandeln wir Dokumentation als integralen Bestandteil des Testens und sorgen für starke Rückverfolgbarkeit zur Erleichterung von Audits.

Die Einhaltung von Normen wie IEC 62304 und ISO 13485 wird durch einen strukturierten Testansatz sichergestellt: Unit-, Integrations- und Systemtests.

Strikte Rückverfolgbarkeit zwischen Anforderungen, Risiken und Testergebnissen erhöht die Transparenz und das Vertrauen. Frühes, risikoorientiertes Testen führt zu höherer Zuverlässigkeit und reibungsloseren regulatorischen Genehmigungen.

 

Fazit

Als Ingenieurteam im Bereich Medizintechnik betrachten wir das Testen als einen kontinuierlichen Prozess während der gesamten Entwicklung – einschließlich Regressionstests und Dokumentationsaktualisierungen. Unser Ansatz gewährleistet Softwarequalität, funktionale Korrektheit und Validierung im realen Einsatz.

Gute Ingenieurpraktiken und die Einhaltung medizinischer Softwarestandards sind das Fundament unserer Strategie – und führen letztlich zu sichereren und besseren Medizinprodukten.