Unter Unit-Testing wird in der Software-Entwicklung das Testen von Software-Units verstanden. Allerdings gibt es weder ein einheitliches Verständnis darüber,
- was eine Software-Unit ist,
- was einen guten Unit-Test auszeichnet und
- welche regulatorischen / gesetzlichen Anforderungen erfüllt werden müssen.
Dieser Artikel verschafft Klarheit.
1. Testobjekte: Was beim Unit-Testing getestet wird
a) Übliches Verständnis von Software-Units
Beim Unit-Testing werden abgegrenzte Teile eines Software-Systems getestet. Je nach Größe dieser Teile bezeichnet man diese Unit-Tests auch als
- Komponententests,
- Modultests oder
- Klassentests.
D.h. die Units entsprechen Komponenten, Modulen oder Klassen.
Unabhängig von ihrer Art bzw. Größe müssen diese „Units“ Schnittstellen anbieten wie beispielsweise die
- Methoden einer Java-Klasse,
- REST-API eines Micro-Services,
- API einer C++-Bibliothek oder
- Java-Script-API eines Webassemblys.
b) Besonderes Verständnis der IEC 62304 von Unit-Tests
Für die Entwicklung von Medizinprodukten und IVDs ist die Norm IEC 62304 relevant. Auch sie kennt Software-Einheiten, auf Englisch Software Units. Diese Software-Einheiten definiert sie als:
„Software-Komponente, die nicht in weitere Komponenten unterteilt ist“.
Damit hängt die Granularität der Software-Units von der Zerlegung des Software-Systems in der Software-Architektur ab (s. Abb. 1).
Die Abb. 1 markiert die Software-Units (im Sinne der Norm) als rote Komponenten. Hingegen verstehen Entwicklerinnen und Entwickler unter Units (beim Unit Testing) meist die Komponenten auf der untersten Ebene (in weiß dargestellt).
2. Testzeitpunkt: Wann das Unit-Testing erfolgt
Die Hersteller sollten die Unit-Tests während, spätestens unmittelbar nach der Entwicklung jeder einzelnen Software-Unit implementieren und durchführen. Erst wenn die einzelnen Software-Units erfolgreich getestet wurden, sollten sie diese stückweise integrieren und dabei Integrationstests unterziehen (s. Abb. 2).
Erst zum Schluss wird das komplette Software-System getestet (z.B. Lasttests unterzogen), bevor anschließend die Validierung (z.B. die Usability-Tests) erfolgt.
3. Testziele: Was das Unit-Testing prüfen kann
Das Unit-Testing soll einen Beitrag zu „guter Software“ leisten. Die ISO 25010 nennt die Software-Qualitätseigenschaften (Qualitätsziele).
| Qualitätsziele gemäß ISO 25010 | Beitrag der Unit-Tests zum Erreichen des Qualitätsziels |
| Funktionalität | Unit-Tests können die funktionale Korrektheit prüfen (z.B. ob Formel richtiges Ergebnis berechnet). Ob eine Software die funktionalen Anforderungen abdeckt, finden die Unit-Tests nur dann heraus, wenn diese Funktionen definiert und implementiert wurden. |
| Robustheit | Unit-Tests können überprüfen, ob Software-Units stabil gegen Fehleingaben sind. |
| Gebrauchstauglichkeit | Die Gebrauchstauglichkeit ist beim Unit-Testing meist kein Testziel. |
| IT-Sicherheit | Unit-Tests können ausgewählte Aspekte der IT-Sicherheit prüfen wie beispielsweise die korrekte Ver- und Entschlüsselung von Inhalten. |
| Performanz | Unit-Tests sollten auch Performanz-Probleme (lange Berechnungsdauern, hoher Ressourcen-Verbrauch) bereits auf Ebene der Software-Units identifizieren. Denn diese Probleme sind in umfangreichen Software-Systemen schwerer zu verorten. |
| Wartbarkeit | Bereits die Tatsache, dass sich die Komponenten (Software-Units) einzeln und unabhängig bei Unit-Tests testen lassen, spricht für die schwache Kopplung der Komponenten und damit für die Wartbarkeit des Software-Systems. |
| Portierbarkeit | Meist überprüfen die Unit-Tests nicht die Portierbarkeit. Diese Übertragbarkeit auf andere Laufzeitumgebungen aus Hard- und Software prüfen die Hersteller meist mit dem ganzen Software-System. |
| Interoperabilität | Die Interoperabilität bezieht sich auf das Zusammenspiel von zwei oder mehr Software-Systemen oder Komponenten. Daher ist die Interoperabilität meist das Testziel von Integrations- und Systemtests |
4. Testmethoden: Was gute Unit-Tests auszeichnet
Ein gutes Unit-Testing zeichnet sich dadurch aus, dass
- die Fehler (sprich Abweichungen von den Qualitätszielen) möglichst vollständig gefunden werden,
- diese Fehler möglichst früh gefunden werden und
- der Aufwand für das Testen möglichst gering ist.
Eine gute Testmethodik hilft, diese Ziele zu erreichen (Tabelle 2).
| Ziel | Methoden zur Zielerreichung (Beispiele) |
| Fehler vollständig finden | Die Entwicklerinnen und Entwickler sollten die Testfälle systematisch ableiten. Dafür stehen Blackbox-Testmethoden wie das äquivalenzklassen- und grenzwertbasierte Testen zur VerfügungZusätzlich sollte das Entwicklungsteam die Kenntnisse des Source-Codes beim Festlegen der Testfälle nutzen. Dazu zählt auch, dass sie ein Mindestniveau für die Code-Coverage bestimmen und erreichen. |
| Fehler möglichst früh finden | Fehler finden sich besonders früh, wenn die Unit-Tests parallel mit dem zu prüfenden Code geschrieben werden. Daraus folgt die Regel, dass für jede Software-Unit bzw. jedes Software-Modul bzw. jede Software-Komponenten zwingend immer die zugehörigen Unit-Tests entwickelt werden müssen.Die automatisierte und regelmäßige Ausführung von Unit-Tests als Regressionstests hilft, Fehler, die durch die Änderung des Codes eingeführt werden, schnellstmöglich zu finden und wieder zu beseitigen. |
| Aufwand für das Testen minimieren | Es gibt Software-Werkzeuge, welche nicht nur Skeletons von Testmethoden, sondern sogar einfach Implementierungen von Unit-Tests generieren. Bei der modelbasierten Entwicklung z.B. mit Domain Specific Languages kann diese automatische Generierung besonders weit getrieben werden.Die Automatisierung erspart das wiederholte manuelle Anstoßen der Unit-Tests und das Schreiben der Fehlerprotokolle. |
5. Regulatorische Anforderungen an das Unit-Testing
a) Anforderungen der IEC 62304
Die IEC 62304 kennt kein „Unit Testing“. Vielmehr erwartet sie eine Prüfung, ob die Software-Einheiten (auf Englisch Software Units) vorher festgelegte Akzeptanzkriterien erfüllen.
Abhängig von der Sicherheitsklasse (hier mehr dazu)
- können Hersteller sogar auf diese Verifizierung verzichten (Klasse A) oder
- die Akzeptanzkriterien so bestimmen, dass sich diese nur mit einer Analyse des Quellcodes (z.B. Code Review, statische Code-Analyse) überprüfen lassen (Klasse B),
- oder sie müssen tatsächlich die Software-Einheit testen, d.h. ein Unit-Testing durchführen.
In jedem Fall sind die Hersteller verpflichtet, diese Prüfungen zu planen, spezifizieren und dokumentieren.
Viele Hersteller verstehen unter dem Unit-Testing das Testen von Methoden oder Funktionen und gehen (bei OO-Entwicklungen) runter bis auf die einzelnen Klassen (weiße Kästchen in Abb. 1). Im Architekturdokument sind als kleinste Komponenten aber nur viel grob-granularere Teile der Software erkennbar (rote Kästchen in Abb. 1) — und genau das sind die Software-Einheiten im Sinne der Norm.
Mit anderen Worten: Die Software-Entwickler testen sehr feingranular (und nennen das Unit Testing), testen aber nicht die in der Software-Architektur spezifizierten Software-Einheiten. Und das ist ein Verstoß gegen die IEC 62304.
b) Anforderungen der FDA an Unit-Tests
Die FDA formuliert ihre Vorstellungen vom Unit Testing in den Guidance Dokumenten z.B. im „Software Validation Guidance„. Sie nennt diese Tests „Tests for Modules and Functions“, die sich auf der einen Seite in den Source Code und auf der anderen zurück zur Architektur verfolgen lassen müssen.
Ähnlich wage formuliert die FDA die Anforderungen an die „Verification and Validation“ im Guidance Document „Content of the Premarket Submissions for Software contained in Medical Devices„.
Umso überraschender ist angesichts solch unpräziser Vorgaben, dass 100% Zweigabdeckung „is considered to be a minimum level of coverage for most software products, but decision coverage alone is insufficient for high-integrity applications“. Diese Forderung haben die Software-Experts des Johner Instituts noch bei keiner Firma als erfüllt vorgefunden.
6. Tipps zum Unit Testing
Tipp 1: Wählen Sie die richtige Granularität
Vermeiden Sie die oben erwähnte typische Falle, dass Sie zahllose Unit-Tests durchführen, aber die Software-Einheiten nicht explizit testen. Das bedingt jedoch, dass Sie überhaupt isoliert testbare Software-Einheiten haben. Und dies wiederum ist eine Frage der Güte Ihrer Architektur.
Ergänzen Sie also Ihre Unit-Tests (gemäß Ihrer Definition) durch die Tests der wahrscheinlich grob-granulareren Software-Einheiten.
Tipp 2: Nutzen Sie schlimmstenfalls Akzeptanzkriterien statt Unit-Testing
Wenn Sie aus Zeitgründen oder wegen einer verkorksten Software-Architektur Ihre Software-Einheiten nicht (automatisiert) testen können, dann legen Sie bei Software-Einheiten der Klasse A und B zumindest formale Akzeptanzkriterien fest, wie Kodierrichtlinien, Metriken oder Namenkonventionen. Das hat zwar wenig mit professionellem Software-Engineering zu tun, erfüllt aber wenigstens die wenigen Anforderungen der IEC 62304. Bei Software der Klasse C bleibt Ihnen dieser Kunstgriff verwehrt.
Bei Klasse C müssen Sie als Teil der Akzeptanzkritierien (soweit anwendbar) auch Performanz-Aspekte, Fehlerbehandlung, Speicherauslastung usw. prüfen. Generell sollten die Akzeptanzkritieren von Unit-Tests die in der Software-Architektur spezifizierten Anforderungen sein.
Tipp 3.: Setzen Sie Werkzeuge fürs Unit-Testing ein
Automatisieren Sie auch diese Tests, um sie als Regressionstests (idealerweise täglich) wiederholen zu können.
Das bedingt, dass Sie Unit-Testwerkzeuge wie JUnit, NUnit oder CppUnit ebenso im Einsatz haben, wie Werkzeuge für die kontinuierliche Integration wie sie Kombinationen von ANT, make, Maven, Grunt im Zusammenspiel mit Continous Integrationstools wie beispielsweise Jenkins/Hudson erlauben.
Für die statische Code-Analyse z.B. Analyse der Code-Metriken gibt es ebenfalls zahlreiche Werkzeuge, ebenso für das Bestimmen des Code-Coverage.
Für die Verwaltung des Unit-Test-Code und der Testergebnisse sind Versionsverwaltungssysteme wie git hilfreich.
Die ISO 13485 fordert allerdings die Validierung der Werkzeuge! Lesen Sie hier mehr zur Validierung von Werkzeugen.
Werkzeuge können nicht immer bewerten, ob der Test erfolgreich war. Beispielsweise bestimmt ein Tool den Statement-Coverage-Grad mit 62%. Doch ist damit das Akzeptanzkriterium erfüllt? Genau diese Bewertung verlangt die IEC 62304.
Software as a Medical Device leicht gemacht
Entdecken Sie jetzt, wie Sie Ihre Software als Medizinprodukt in Verkehr bringen können. Erfahren Sie alles über die IEC 62304 Norm und lernen Sie, wie Sie die Anforderungen einfach und praxisorientiert umsetzen können. Mit über 25 Videos und einem kompletten Set einer IEC 62304-konformen Software-Akte unterstützen wir Sie dabei, Ihre Software erfolgreich und schnell zu vermarkten
7. Fazit, Zusammenfassung
Die Anforderungen der IEC 62304 an das Unit-Testing sind überschaubar und liegen eher unterhalb dessen, was man als Stand der Technik bezeichnet.
Unit-Tests sind die „Versicherung“ für jeden Software-Hersteller. Dank vieler Werkzeuge sind sie schnell implementiert und ausgeführt. Das methodische Wissen, wie man Unit-Tests schreibt, ersetzen sie aber nicht.
Das Team des Johner Instituts unterstützt IVD- und Medizinproduktehersteller beim Unit-Testing:
- Im Auditgarant stellt es zahlreiche Templates zur Verfügung z.B. einen IEC 62304-konformen Entwicklungsplan. Dieser wiederum fordert die Unit-Tests.
- Zahlreiche Videos im Auditgarant sowie der Johner Academy erläutern die Anforderungen der IEC 62304 und geben konkrete Tipps, um diese Anforderungen schnell und einfach zu erfüllen.
- Das Beratungsteam hilft bei der Prüfung von Entwicklungsplänen und beurteilt auf Wunsch die komplette Software-Akte. So gelingt eine schnelle Zulassung der Produkte.
- Mit Penetrationtests decken die IT Security Experts des Johner Instituts (bisher) immer Schwachstellen auf. So lassen sich diese beseitigen, bevor sie in der Praxis zu Problemen führen.
- Im Micro-Consulting geben die Software-Expert Antworten auf kurze Fragen. Nicht nur zum Unit-Testing.
Änderungshistorie
- 2024-08-14: Artikel komplett neu geschrieben
- 2016-11-16: Erste überarbeitete Version des Artikels veröffentlich