51608.jpg

In 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. Obwohl diese Richtlinien für amerikanischen Markt gelten, kommen auch europäische Medizintechnik-Hersteller nicht umhin, sich dafür zu interessieren.

Auf einen Blick

Nicht nur wer Medizinprodukte für den internationalen Markt entwickelt, sollte die Regularien der FDA kennen. Im Bereich Test gibt es drei Prüfstufen: 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 Steuerungs Informationen 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.

Einen deutlichen Anstoß gibt 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 kann die Auffassung vertreten, dass DIN EN 62304 zusammen mit den FDA GPoSV den Stand der Technik zur Ausführung einer Software-Validierung beschreiben. Außerdem 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.

Testprozess laut FDA-Empfehlungen

Die FDA empfiehlt in Bezug auf den Software-Testprozess, dass

  • dieser unabhängig von der Codeerstellung sein sollte und
  • Prüfer andere Werkzeuge benutzen sollten als Code-Ersteller.

Bild 1: Testbench: Modul-/Integrationstest mit Test-Treiber, Dummy-Funktionen und realen Funktionen.

Bild 1: Testbench: Modul-/Integrationstest mit Test-Treiber, Dummy-Funktionen und realen Funktionen.Vector Software

Beide Aussagen legen 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.

Eine mögliche Lösung 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.

Bild 2: Einsatz eines Runtime Support Package (RSP) für den Modul-/Integrationstest auf dem Zielsystem.

Bild 2: Einsatz eines Runtime Support Package (RSP) für den Modul-/Integrationstest auf dem Zielsystem.Vector Software

Einige Test-Automatisierungswerkzeuge ermöglichen auch das Ausführen von Modul- und Integrationstests auf einem Simulator, Emulator oder dem Embedded-Zielsystem. Für die Unterstützung der verschiedenen Hardware-Anforderungen verwendet man ein Runtime Support Package (RSP, Bild 2).

Strategien

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.

Bild 3: In der Praxis haben sich sowohl traditionelle am Wasserfall-Modell orientierte Testmethoden bewährt, als auch der Top-Down-Ansatz beginnend bei den Requirements.

Bild 3: In der Praxis haben sich sowohl traditionelle am Wasserfall-Modell orientierte Testmethoden bewährt, als auch der Top-Down-Ansatz beginnend bei den Requirements.Vector Software

Bild 3 zeigt verschiedene Teststrategien im Softwareentwicklungs-Lebenszyklus. Zwar empfiehlt die FDA, mit dem Modultest zu beginnen, dies ist aber manchmal nicht machbar. Besonders bei der Zertifizierung einer älteren Anwendung wäre es zu aufwändig, für jedes einzelne Modul einen Modultest durchzuführen. Ein anderer gangbarer Weg ist, mit einem Systemtest zu beginnen und den Modultest auf solche Module zu beschränken, die beim Systemtest nicht mit ausreichender Fehlerabdeckung geprüft wurden.

Automatisierung

Automatisierte Testwerkzeuge unterstützen sowohl den Bottom-up- wie auch den Top-down-Ansatz. Dabei ist es möglich, Informationen über die Codeabdeckung zwischen den verschiedenen Testphasen auszutauschen. Durch Nutzung des Quellcodes mit einem automatischen Testwerkzeug (wie in Bild 4 gezeigt) kann man Codeabdeckungs-Informationen aus dem Systemtest archivieren.

Bild 4: Ermittlung der Prüfabdeckungsdaten aus dem Systemtest.

Bild 4: Ermittlung der Prüfabdeckungsdaten aus dem Systemtest.Vector Software

Aus Sicht der FDA ist „das erwartete Ergebnis ein zentrales Element eines Softwaretests“. Dabei ist es nicht nur wichtig, dass ein automatisiertes Testwerkzeug die einfache Definition erwarteter Werte für einen Testfall erlaubt. Manche Tools lassen sich sogar mit einem Werkzeug zur Verwaltung von Anforderungen oder mit einem Lebenszyklus-Verwaltungswerkzeug (PLM, Product Lifecycle Management) integrieren. Damit ist es problemlos möglich, die erwarteten Werte entsprechend den Anforderungen (Requirements) zu ermitteln (Bild 5). Nach den GPoSV-Empfehlungen sollten die erwarteten Werte „aus der entsprechenden, zuvor festgelegten Definition oder Spezifikation abgeleitet werden“.

Struktureller Test (White-Box)

Bild 5: Beispiel einer grafischen Bedieneroberfläche für einen Modul-Schnittstellentest mit Verweis auf die entsprechende Anforderung.

Bild 5: Beispiel einer grafischen Bedieneroberfläche für einen Modul-Schnittstellentest mit Verweis auf die entsprechende Anforderung.Vector Software

Manche Qualitätssicherungs-Strategien konzentrieren sich auf die Verifikation von Anforderungen und sind vollständig unabhängig vom Quellcode; demgegenüber empfiehlt die FDA ausdrücklich einen strukturellen Test:

  • Ein Software-Produkt sollte mit Testfällen überprüft werden, die aus der internen Struktur der Software abgeleitet sind.
  • Testfälle sollten auf Wissen beruhen, das aus dem Quellcode abgeleitet wurde.
  • Ein struktureller Test lässt sich anhand von Bewertungsmaßstäben auswerten […], die man meist als Prüfabdeckung bezeichnet.

Die GPoSV-Empfehlungen verweisen auf eine Publikation über den strukturellen Test auf Grundlage einer Basis Path Analyse anhand des Bewertungsmaßstabs der zyklomatischen Komplexität nach McCabe (NIST Special Publication 500-235, Structured Testing: A Testing Methodology Using the Cyclomatic Complexity Metric, 1997).

Bild 6: Beispiel einer Decision Prüfabdeckungs-Programmdarstellung in einem automatisierten Testwerkzeug (hier: MC/DC-Prüfabdeckung).

Bild 6: Beispiel einer Decision Prüfabdeckungs-Programmdarstellung in einem automatisierten Testwerkzeug (hier: MC/DC-Prüfabdeckung).Vector Software

Codeabdeckung

Automatisierte Testwerkzeuge können nützlich sein für die Ermittlung der Codeabdeckung (Bild 6), da sie unter anderem den Code für die Ermittlung der Codeabdeckungsinformationen aus dem Modul-, Integrations- und Systemtest ermitteln. Außerdem können automatisierte Testwerkzeuge durch eine Analyse des Quellcodes selbstständig Testfälle generieren, die bei Ausführung das gewünschte Maß an Codeabdeckung (zum Beispiel Statement-, Verzweigungs-, Decision-Abdeckung…) erzielen. Solche automatisch generierten Testfälle enthalten keine erwarteten Werte – diese sollte man manuell auf der Basis von Anforderungen eingeben und nicht automatisch anhand des Codes ermitteln.

Die automatisch auf der Grundlage von Basis-Paths erzeugten Testfälle bieten oft eine hohe Statement-Prüfabdeckung (Basis-Paths sind jeweils unabhängige Pfade durch den Kontrollfluss des Programms). Die Anzahl der Testfälle entspricht der zyklomatischen Komplexität des Programms (Komplexitätsmaß nach McCabe). Auf Grundlage dieser Analyse kann das Werkzeug automatisch Testfälle generieren, die bei ihrer Ausführung eine Statement- und Verzweigungs-Codeabdeckung von 100 Prozent erreichen. Zusätzlich wird die Komplexität der Funktion ermittelt. Die Komplexität und die zusammengefassten Codeabdeckungs-Informationen aus allen Testfällen lassen sich mit einem automatisierten Testwerkzeug ermitteln.

Funktioneller Test (Black-Box)

Zusätzlich empfiehlt die FDA auch, dass „ein Softwareprodukt anhand von Testfällen überprüft werden sollte, die aus deren externer Spezifikation abgeleitet wurden“. Die GPoSV-Empfehlungen erwähnen die folgenden Arten von funktionellen Tests:

  • Normalfall – eine Überprüfung mit den üblichen Eingangsdaten ist erforderlich.
  • Output Forcing – ausgewählte (oder alle) Software-Ausgangszustände werden durch den Test erzeugt.
  • Robustheit – unerwartete oder ungültige Eingangsdaten […] Partitionierung nach Äquivalenzklassen, Grenzwertanalyse und die Ermittlung von Sonderfällen (Error Guessing).
  • Kombination von Eingangszuständen – Berücksichtigung einer Kombination der oben ermittelten Eingangszustände.

Automatisierte Testwerkzeuge können den Wertebereich der Parameter einer Funktionsschnittstelle untersuchen. Anhand dieser Analysen lassen sich automatisch Testfälle erzeugen, die die Funktion mit MIN-1, MIN oder MAX und MAX+1 stimulieren. Dabei ist zu beachten, dass in manchen Fällen aufgrund eines Datenüberlaufs MIN-1 gleichbedeutend ist mit MAX, und MAX+1 gleichbedeutend mit MIN ist. Andererseits können diese Testparameter in Situationen sinnvoll sein, bei denen der Typenbereich unabhängig von den benutzten Bits eingeschränkt ist.

Zwischenwerte

Eine Funktionsschnittstelle lässt sich auch mit einer Reihe von Werten zwischen MIN und MAX oder zwischen MIN-1 und MAX+1 testen, wobei diese Routine entweder einmal pro Schritt oder mit allen Kombinationen der Eingangswerte ausgeführt werden.

Bild 7: Automatisch erzeugter und partitionierter Testfall auf der Basis einer Grenzwert-Analyse für die Schnittstellenparameter.

Bild 7: Automatisch erzeugter und partitionierter Testfall auf der Basis einer Grenzwert-Analyse für die Schnittstellenparameter.Vector Software

Bild 7 zeigt einen automatisch generierten Testfall, der die Funktion mit einem Satz von Werten innerhalb der zulässigen Grenzen stimuliert. Die Schrittgröße (Anzahl der Partitionen) ist konfigurierbar; ebenfalls lässt sich einstellen, ob die Funktion einmal pro Schritt oder mit allen möglichen Kombinationen ablaufen soll. Beim Kombinationstest sollte man allerdings vorsichtig vorgehen, da die Anzahl der Testfälle ansonsten exponentiell zunimmt.

Statische Tests

Im Zusammenhang mit funktionellen Tests erwähnen die GPoSV-Empfehlungen auch statistische Tests. Dabei sollen zufällige Werte sowie Werte „auf der Basis eines Betriebsprofils“ dazu dienen, den Quellcode-Funktionsumfang in Bezug auf die Anforderungen zu verifizieren. Die GPoSV-Empfehlungen erwähnen dabei, dass „große Mengen an Testdaten erzeugt werden.“

Ein Softwareentwickler wird eine Funktion mit einer großen Menge an Testdaten wohl kaum manuell überprüfen. Mit automatisierten Testwerkzeugen lassen sich zahlreiche Testfälle zum Beispiel über einen Import von Eingangswerten sowie erwarteten Ausgangswerten aus einer CSV-Datei erstellen (Comma-separated Values). Die CSV-Datei lässt sich entweder über ein modellgestütztes Generierungskonzept für Testwerte oder – wie von der FDA vorgeschlagen – anhand eines Betriebsprofils erzeugen. Automatisierte Test-Tools können dann die Spalten der CSV-Datei mit den Datenfeldern für die Eingangswerte und die erwarteten Ausgangswerte verknüpfen. Anhand der Werte in der CSV-Datei lassen sich zahlreiche Testfälle automatisch und ohne die Notwendigkeit manueller Eingriffe erstellen, ausführen und im Vergleich zu den erwarteten Ausgangszuständen verifizieren.

Regressionstests

Die FDA erwähnt in den GPoSV-Empfehlungen auch Softwareänderungen, und wie man mit diesen in Bezug auf Tests umgeht. Softwareänderungen können aus unterschiedlichen Gründen notwendig werden:

  • Fehlerkorrekturen
  • Neue oder veränderte Anforderungen
  • Design-Modifikationen (effektivere oder effizientere Implementationen)
  • Kontinuierliche Integration
  • TDD (Test Driven Development)

Die FDA erwähnt Regressionstests ausdrücklich als eine wichtige Möglichkeit, mit der Softwareentwickler das Risiko der Einführung unerwünschter Nebeneffekte bei Codeveränderungen an der Software minimieren können: „Regressionstests (die wiederholte Ausführung von Testfällen, die ein Programm früher schon einmal korrekt ausgeführt hat, und der Vergleich der aktuellen Ergebnisse zu früheren Ergebnissen, um unbeabsichtigte Auswirkungen einer Softwareänderung zu ermitteln) sollen ausgeführt werden… um sicherzustellen, dass eine Veränderung keine Probleme an einer anderen Stelle im Softwareprodukt verursacht.“

Fehler nicht wiederholen

Softwareentwickler werden Regressionstests nicht manuell ausführen wollen. Ein zuvor erzeugter Testfall sollte ohne jeglichen manuellen Eingriff automatisch ausgeführt werden. Automatisierte Testwerkzeuge können Regressionstests selbsttätig ausführen, zum Beispiel jede Nacht oder unmittelbar, wenn eine Codeveränderung in die Codebasis eingetragen wird.

Bild 8: Die Hockeyschläger-Kurve zeigt die Fehlerbehebungskosten als Funktion der vergangenen Zeit nach Einführung des Fehlers.

Bild 8: Die Hockeyschläger-Kurve zeigt die Fehlerbehebungskosten als Funktion der vergangenen Zeit nach Einführung des Fehlers.Vector Software

Die enge Verknüpfung einer Softwareänderung mit einer neu eingeführten Fehlfunktion ist entscheidend, da Arbeitsaufwand und -Kosten für die Korrektur eines Fehlers stark zunehmen, je mehr Zeit bis zur Erkennung und Behebung vergeht (Bild 8). Regressionstests sind daher eine zentrale Funktion von automatisierten Testwerkzeugen.

Qualitätsniveau

Die GPoSV-Empfehlungen fordern, dass „Software-Testwerkzeuge ein Qualitätsniveau bieten sollten, das nicht geringer sein darf als das des Softwareprodukts, das damit entwickelt wird. Entsprechende Dokumentation sollte mit einem Nachweis der Validierung dieser Softwarewerkzeuge für den beabsichtigten Einsatz gepflegt werden.“ Einige Software-Testwerkzeuge haben einen formalen Zertifizierungsprozess durchlaufen und wurden zum Beispiel nach IEC 61508 oder ISO 26262 zertifiziert. Diese Werkzeuge werden mit folgender Dokumentation geliefert:

  • Ein Zertifikat der Prüforganisation als Beleg für die Zertifizierung.
  • Anforderungen für den Betrieb des Werkzeugs (TOR – Tool Operational Requirements): Dieses Dokument enthält überprüfbare Anforderungen für das Werkzeug oder den zu überprüfenden Übersetzer zusammen mit Informationen über die Arbeitsumgebung des Projekts, die einen Einfluss auf die vom Werkzeug gelieferten Ergebnisse haben können (zum Beispiel Mikroprozessor-Architektur).
  • Werkzeug-Qualifizierungsdaten (TQD– Tool Qualification Data): Beschreibt die Testdaten und die Ergebnisse aus der Serie der Qualifikationstests, die zur Verifikation aller Anforderungen in den TOR unter Nutzung der Arbeitsumgebung des Projekts erforderlich waren.
  • Compliance-Analyse nach IEC 61508/ISO 26262: Diese Informationen werden typischerweise in einem Workflow-Handbuch erfasst, das den Einsatz des Werkzeugs innerhalb vorgegebener Grenzbedingungen beschreibt. Dies gewährleistet, dass die damit erzeugten Ergebnisse die Erfüllung der Norm hinreichend belegen.

Das passende Werkzeug

Um die GPoSV-Empfehlungen zu erfüllen, empfiehlt die FDA den Einsatz automatisierter Testwerkzeuge. Dabei ist die Auswahl des richtigen Werkzeugs ein wichtiger Prozess für ein Unternehmen, da es starke Auswirkungen auf die täglichen Arbeitsabläufe hat. Damit sich diese Investition schnell rentiert, sollte ein Unternehmen Folgendes tun:

  • Die infrage kommenden Werkzeuge mit Code evaluieren, der repräsentativ für den Programmcode des Unternehmens ist.
  • Die Werkzeuge mit den gleichen Tools überprüfen, die auch für reale Projekte im Hause verwendet werden.
  • Sich bei langjährigen Kunden des Anbieters informieren und diese fragen, ob sie mit dem Anbieter zufrieden sind.
  • Die Fähigkeiten des technischen Supports des Toolanbieters prüfen. Man stellt den Support auf die Probe, indem man direkt Fragen an das Support-Team stellt, und nicht nur an den Vertriebsberater.
  • Untersuchen, wie automatisiert, wie bedienerfreundlich und wie umfassend das Werkzeug und die Produktunterstützung sind.

Wer mehr über die Entwicklung und das Testen von Software für medizinische Geräte erfahren will, dem sei die Linkedin-Gruppe „Software Development for Medical Devices“ empfohlen.

Ingo Nickles

ist Field Application Engineer bei Vector Software in Kempen.

(lei)

Sie möchten gerne weiterlesen?

Unternehmen

Vector Software Inc.

1351 South County Trail, Suite 310
02818 East Greenwich, RI
Germany