Wirtschaftlich testen: Softwaretests in der Medizintechnik (Matthias Kraaz)

MED Informatik Softwaretests

48

sich so frühzeitig reagieren, und böse Überraschungen lassen sichbei der formellen Verifizierung vermeiden. Eine solche Vorgehens-weise erhöht zunächst den Aufwand, amortisiert sich jedoch schnell. Systemtests sind aufwändig in der Erstellung und Durchführung.Schlägt ein Test fehl, ist die Lokalisierung der Ursache ebenfallsaufwändig. Zudem kann mit Systemtests erst begonnen werden,wenn ein testbares Sys-tem verfügbar ist. Dahersind auch Komponenten-und Integrationstests rat-sam, da viel früher getestet werden kann. Fehler werden so frühergefunden und behoben. Beim Komponententest werden die kleins-ten, nicht weiter sinnvoll zerlegbaren Einheiten eines Systems ge-testet. Sie werden oft auch als Unit-Tests bezeichnet. Tauchen hierFehler auf, lässt sich mit geringem Aufwand die Ursache finden undbeheben. Gleichzeitig ist die Stimulation des Prüflings wesentlicheinfacher, was den Aufwand für die Testerstellung und die Laufzeit

der Tests reduziert, die Testabdeckung abererhöht. Die vorgetesteten Komponenten wer-den dann schrittweise integriert und wieder-um getestet. Bei diesen Integrationstests tauchen wesent-lich weniger Fehler auf als mit ungetestetenKomponenten. Die Fehler resultieren aucheher aus dem Zusammenspiel der Kompo-nenten und nicht aus intrinsischen Fehlernder Komponenten selbst. Mit diesem Wissenlässt sich die Ursache wiederum schneller fin-den und beheben. Komponenten- und Inte-grationstest reduzieren daher die Anzahl derteuren Systemtests, ohne die Zuverlässigkeitder Testergebnisse zu mindern. Aus dieserVorgehensweise ergeben sich sehr viele Kom-ponententests, viele Integrationstests, aberwesentlich weniger Systemtests. In der agilenCommunity wird der Aufbau der Teststufenaufeinander und das Zahlenverhältnis derTests durch die sogenannte Testpyramide(Bild 1) dargestellt.Da einzelne Komponenten nicht vom Testerdirekt stimuliert werden können, ergibt sichdie Automatisierung von Komponenten- und

MED engineering 9-10 2012

Softwaretests bieten ein großes Potential zur Effizienzsteigerung. Die Qualität des Produkts lässt sich erhöhen, die Freigabezeit verkür-zen und so die Kosten senken, sofern man die Tests früh integriert.

Wirtschaftlich testen

Frühes Testen vermeidetÜberraschungen

1 Automatisierungspyramide für das Testen von Software: relativer Anteil derTeststufen [1]

System-tests

Integrationstests

Komponententests

© MED engineering

Viele aktive Medizinprodukteenthalten Software, undSoftware enthält normaler-

weise Fehler. Daher verlangenGesetzgeber umfangreiche Testsvon Software und System. Häufigwerden während der Produktent-wicklung unsystematisch zu allenSystemanforderungen Testfälle spe-zifiziert und ausgeführt, sobald dieEntwicklung abgeschlossen ist. Eswerden also nur manuelle System-tests durchgeführt. Effizienter ist es,schon während der Entwicklung zutesten und die Entwickler mit früh-zeitigen Fehlerberichten zu unter-stützen. Auf Qualitätsprobleme lässt

»Es lohnt sich

Komponenten vor-

zutesten.«

48-51 MD110172_Zuehlke_EF-ahx 21.08.2012 16:32 Uhr Seite 48

Internet-PDF-Datei. Diese PDF Datei enthält das Recht zur unbeschränkten Intranet- und Internetnutzung, sowie zur Verbreitung über elektronische Verteiler. Eine Verbreitung in gedruckter Form ist mit dieser PDF-Datei nicht gestattet.

49

Integrationstests fast zwangsläufig und stellt im Allgemeinen kei-ne Herausforderung dar. Anders ist es mit Systemtests: Spätes-tens hier müssen sinnvolle Tests die Hardwareschnittstellen desSystems stimulieren und beobachten. Die Messtechnik, die spä-ter in der Produktion für funktionale Tests verwendet wird, kannzum Beispiel auch für die Automatisierung von Systemtests ge-nutzt werden. Man sollte aber nicht versuchen, alle Systemtestszu automatisieren. Bewährt hat sich die 80/20-Daumenregel.Bei der Gestaltung der Testskripte für automatisierte Systemtestsist eine gesunde Mischung aus kurzen und langen Tests empfeh-lenswert. Kurze Testskripte lassen sich einfacher entwickeln undändern. Außerdem werden Fehler leichter gefunden, gleich ob sieim Prüfling, in der Testinfrastruktur oder im Testskript liegen. Man-che Fehler werden aber erst durch lange Testskripte oder aufei-nander aufbauende kurze Testskripte entdeckt.Der Vorteil automatisierter Systemtests (Bild 2) ist schwierig zuquantifizieren. Der Aufbau der Infrastruktur kostet Zeit und Geld,

dafür entdeckt manFehler früher und ver-kürzt die Entwick-lungszeit. Die Tester-

gebnisse sind zuverlässiger, da Bedienfehler ausgeschlossen wer-den können. Ein Fehlschlag bei den Freigabetests wird unwahr-scheinlich, da die meisten Systemtests permanent laufen. Automatisierte Tests benötigen Schnittstellen, über die der Prüf-ling stimuliert (Point of Control, PoC) und überwacht (Point of Ob-servation, PoO) wird. Die geschickte Wahl von PoC und PoO be-stimmt, wie aufwändig die Implementation der Tests ist, wieschnell sie ablaufen und ob sie auch bei eigentlich irrelevanten Än-derungen am Prüfling überarbeitet werden müssen. Beim Reviewvon Designdokumenten sollte das Testteam daher auf die Test-barkeit achten, also überlegen, wie das System oder die Kompo-nente stimuliert und das Verhalten überwacht werden kann. Ambesten wird bereits beimArchitekturentwurf eineTeststrategie entworfenund die PoOs und PoCs fest-legt. Die Testbarkeit der Ar-chitektur ist ein Hebel, derdie Kosten automatisierterSystemtests immens sen-ken oder erhöhen kann.

Die formelle Verifizierung besteht oft aus einer großen Anzahl ma-nuell durchgeführter Systemtests. Ein Fehlschlag von einem odermehreren Tests bei der formellen Verifizierung ist eine teure Sa-che. Der Fehler muss behoben und danach sämtliche Verifizie-rungstests wiederholt werden. Diese Schleife wird so lange durch-laufen, bis keine Fehler mehr auftreten. Ein mehrfaches Durchlau-fen der Schleife hat große Auswirkungen auf die Einhaltung vonTerminen und Budgets. Verifizierungstests haben daher grund-sätzlich einen anderen Charakter als entwicklungsbegleitendeTests. Um auch Verifizierungstests zu automatisieren, muss die Testinfra-struktur validiert werden. Beim Entwurf der Testinfrastruktur soll-

MED engineering 9-10 2012 www.med-eng.de

Zühlke Engineering GmbH65760 Eschborn Tel. +49 (0)6196 777540Fax +49 (0)6196 77754-54www.zuehlke.com

Kontakt

Automatisierte Testsschließen Bedienfehler aus

2 Automatisierte Systemtests erzeugen zwar Aufwand, dafür entdeckt man Fehler früher und verkürzt die Entwicklungszeit

Bild

2: D

r. G

eorg

Mol

ter,

Zü

hlk

e En

gin

eeri

ng

Gm

bH



50

te schon an die spätere Validie-rung gedacht werden. Eine Infra-struktur für automatisierte Testskann Komponenten enthalten, diedie Erstellung der Testfälle und dieUntersuchung von Fehlern erleich-tern. Solche Komponenten werdenaber für die Verifizierungstests nichtbenötigt und brauchen nicht vali-diert zu werden, wenn sie bei Verifi-zierungstests entfernt werden kön-nen. Durch einen geschickten Ent-wurf der Testinfrastruktur lässt sichalso der Validierungsaufwand redu-

zieren. Sicherlich wird man nichtalle Verifizierungstests automa-

tisieren. Wenn aber die Mehr-zahl automatisiert ist, kön-

nen sie schon entwick-lungsbegleitend re-

gelmäßig ausgeführtwerden. Damit wirddas Ergebnis der Ve-

rifizierung vorhersag-bar und ein Durchfallen

unwahrscheinlich. Für die Fehlersuche eignen sich

nicht nur dynamische Tests. Be-stimmte Fehlerklassen werdendurch eine werkzeuggestützteAnalyse schneller gefunden. Inner-halb von Minuten kann die gesam-te Code-Basis vollständig unter-sucht werden, nur mit dem Werk-zeug und ohne Infrastruktur. Ledig-

lich die Kosten für die Lizenzierung undKonfiguration des Werkzeugs entstehen.Oft wird die werkzeuggestützte Analyse auf dieÜberprüfung der Einhaltung von Kodierrichtlinien wieMISRA-C [2] beschränkt. Stattdessen sollten unbedingt auch der Kon-trollfluss und der Datenfluss auf Anomalien untersucht werden. Beider Verwendung entsprechender Werkzeuge kommt es immer wie-der zu einer Häufung von Fehlmeldungen, die dann stoisch unter-drückt werden. Das produziert Aufwand, und die Ergebnisse derAnalyse sind nicht soaussagekräftig. Statt-dessen sollte ein Ex-perte für das Werk-zeug hinzugezogen werden, der die Ursache findet und behebt, seies bei der Konfiguration des Werkzeugs oder beim Programmierstilder Entwickler.Werkzeuggestützte Analyse und automatisierte Tests sollten per-manent und von Beginn der Kodierung an laufen, um Entwicklernso früh wie möglich Fehler zu melden. Hier bietet sich ein Continu-ous Integration Server an. Statische Tests nur zum Ende der Imple-mentationsphase sind nicht sinnvoll, weil die Fehler viel zu spät ent-deckt werden. Problematische Idiome haben sich dann im Codeschon stark verbreitet. Der Testaufwand sollte nicht gleichmäßigüber alle Komponenten des Systems oder alle Anforderungen andas System verteilt werden. Wichtigere Komponenten oder Kompo-nenten, die beispielsweise aufgrund ihrer hohen Komplexität mehrFehler enthalten könnten und wichtigere Anforderungen sollten in-tensiver getestet werden.Bugs sind gesellige Tierchen. Wenn in einer Komponente Fehler ge-funden wurden, verstecken sich in ihr wahrscheinlich noch mehrFehler. Die Testintensität der Komponenten sollte daher flexibel an-gepasst werden, um den Testaufwand nicht auf die fehlerarmenKomponenten zu verschwenden.Auch die Herleitung von Testfällen ist gut zu überlegen, um dengrößtmöglichen Nutzen pro Testfall zu erzielen. Allein die Abde-

MED engineering 9-10 2012

Werkzeuggestützte Analyseergänzt die Fehlersuche

3 Reviews sind keinesinnlose Pflichtübung.Je kritischer ein Doku-ment oder ein Code ist,umso intensiversollte der Re-view sein

MED Informatik Softwaretests

Bild

3: D

r. G

eorg

Mol

ter,

Zü

hlk

e En

gin

eeri

ng

Gm

bH

; BU

Gs:

Fot

olia



51

ckung des Kontrollflusses eines getesteten Codes ist kein geeig-neter Maßstab für die Testtiefe. Außerdem muss das zustandsba-sierte Verhalten und das Verhalten bei unterschiedlichen Einga-bedaten berücksichtigt werden. Dazu existieren verschiedene sys-tematische Vorgehensweisen, nach denen man die nützlichstenTestfälle auswählt, beispielsweise Zustandsbaum, Äquivalenzklas-sen- und Grenzwertanalyse, um nur die wichtigsten zu nennen. Reviews haben den Vorteil, zu jedem Zeitpunkt in der Entwicklungfür beliebige Dokumente wie auch für Code durchgeführt werdenzu können. Sie sind keine Pflichtübung, sondern ein probates Mit-tel, um kostengünstig und früher als mit dynamischen Tests Feh-ler zu finden. Die Effektivität von Reviews lässt sich steigern, in-dem die Zeit und Aufmerksamkeit der verfügbaren Reviewer op-timal genutzt wird. Je kritischer ein Dokument oder Code, destointensiver sollte der Review sein. Vor dem Code-Review sollten zu-erst Anomalien und Abweichungen, die die werkzeuggestützteAnalyse gefunden hat, bereinigt werden.

Die agile Entwicklung hat Wege aufgezeigt, Software effizienter zutesten. Mit dem entsprechenden Expertenwissen lassen sich dieseErkenntnisse auf die Entwicklung von Medizinprodukten übertra-gen. Die allgemeine Grundlage bildet der Lehrplan des ISTQB [3]. Zeitist kostbar. Daher sollten die Testaktivitäten sofort bei Projektstartmit der Testplanung und der Mitwirkung beim Architekturentwurfbeginnen. Die Testplanung muss eine an das zu testende System an-gepasste Teststrategie entwickeln. Die Mitwirkung an der Architek-tur stellt die gute Testbarkeit des Systems sicher und ist mit der größ-te Hebel für effizienteres Testen. Eine gute Teststrategie setzt ne-ben Systemtests auch Komponenten- und Integrationstests so-

wie werkzeuggestützte statische Analyse und Reviews ein. DerTestaufwand wird nicht gleichmäßig, sondern nach erwarteterFehlerrate und Priorität der Anforderungen über die Komponen-ten sowie entsprechend der Testpyramide auf die Teststufen ver-teilt. Der Testfallentwurf verwendet systematische Verfahren zurHerleitung der Testfälle.Auch die Durchführung von Tests sollte so früh wie möglich begin-nen und auf allen Teststufen inklusive Systemtest automatisiert wer-den. Die geschickte Auswahl der zu automatisierenden Tests und dieGestaltung der Testskripte erfordern eine gewisse Erfahrung. ZumAbschluss des Testens sollten Verbesserungspotentiale untersuchtwerden. In iterativ-inkrementell arbeitenden Projekten wird die-ser Rückblick oft Retrospektive genannt und sollte für das Testengenauso wie für die Entwicklung gelten.

Literatur

[1] The Tar Pit, Test Automation Pyramid, http://blog.goneopen.com/2010/08/test-automation-pyramid-review/

[2] MISRA-C:2004 – Guidelines for the use of the C language in critical systems,http://www.misra.org.uk/

[3] International Software Testing Qualifications Board, http://istqb.org

MED engineering 9-10 2012 www.med-eng.de

Matthias Kraazist Lead Software Architect bei Zühlke in [email protected]

@MD110172www.med-eng.de

»Was bedeutet

eigentlich

V10.1?«»Das bedeutet, von

zehn Komponenten

funktioniert eine.«



Wirtschaftlich testen: Softwaretests in der Medizintechnik (Matthias Kraaz)

Technology

Transcript of Wirtschaftlich testen: Softwaretests in der Medizintechnik (Matthias Kraaz)