Wirtschaftlich testen: Softwaretests in der Medizintechnik (Matthias Kraaz)

Download Wirtschaftlich testen: Softwaretests in der Medizintechnik (Matthias Kraaz)

Post on 17-Nov-2014

846 views

Category:

Technology

1 download

DESCRIPTION

Softwaretests bieten ein groes Potential zur Effizienzsteigerung. Die Qualitt des Produkts lsst sich erhhen, die Freigabezeit verkrzen und so die Kosten senken, sofern man die Tests frh integriert. Artikel in der MEDengineering 9-10, 2012 von Matthias Kraaz. Kontakt: http://xing.to/kraaz

TRANSCRIPT

1. MED Informatik Softwaretests Softwaretests bieten ein groes Potential zur Effizienzsteigerung. Die Qualitt des Produkts lsst sich erhhen, die Freigabezeit verkr- zen und so die Kosten senken, sofern man die Tests frh integriert.Wirtschaftlich testen Viele aktive Medizinprodukte sich so frhzeitig reagieren, und bse berraschungen lassen sichenthalten Software, und bei der formellen Verifizierung vermeiden. Eine solche Vorgehens-Software enthlt normaler-weise erhht zunchst den Aufwand, amortisiert sich jedoch schnell. weise Fehler. Daher verlangenSystemtests sind aufwndig in der Erstellung und Durchfhrung. Gesetzgeber umfangreiche Tests Schlgt ein Test fehl, ist die Lokalisierung der Ursache ebenfalls sichvon Software und System. Hufigaufwndig. Zudem kann mit Systemtests erst begonnen werden,lo hnt en vor- werden whrend der Produktent- wenn ein testbares Sys-Es nent .wicklung unsystematisch zu allen tem verfgbar ist. Daher Frhes Testen vermeidet omp testenKo zuSystemanforderungen Testflle spe- sind auch Komponenten- berraschungen zifiziert und ausgefhrt, sobald die und Integrationstests rat- Entwicklung abgeschlossen ist. Essam, da viel frher getestet werden kann. Fehler werden so frher werden also nur manuelle System- gefunden und behoben. Beim Komponententest werden die kleins- tests durchgefhrt. Effizienter ist es,ten, nicht weiter sinnvoll zerlegbaren Einheiten eines Systems ge- schon whrend der Entwicklung zu testet. Sie werden oft auch als Unit-Tests bezeichnet. Tauchen hier testen und die Entwickler mit frh-Fehler auf, lsst sich mit geringem Aufwand die Ursache finden und zeitigen Fehlerberichten zu unter- beheben. Gleichzeitig ist die Stimulation des Prflings wesentlich sttzen. Auf Qualittsprobleme lsst einfacher, was den Aufwand fr die Testerstellung und die Laufzeit der Tests reduziert, die Testabdeckung aber erhht. Die vorgetesteten Komponenten wer- den dann schrittweise integriert und wieder- um getestet. Bei diesen Integrationstests tauchen wesent- lich weniger Fehler auf als mit ungetesteten Komponenten. Die Fehler resultieren auchSystem-eher aus dem Zusammenspiel der Kompo-testsnenten und nicht aus intrinsischen Fehlern der Komponenten selbst. Mit diesem Wissen lsst sich die Ursache wiederum schneller fin- Integrationstests den und beheben. Komponenten- und Inte- grationstest reduzieren daher die Anzahl der teuren Systemtests, ohne die Zuverlssigkeit der Testergebnisse zu mindern. Aus dieser Vorgehensweise ergeben sich sehr viele Kom- Komponententestsponententests, viele Integrationstests, aber wesentlich weniger Systemtests. In der agilen Community wird der Aufbau der Teststufen aufeinander und das Zahlenverhltnis der MED engineering Tests durch die sogenannte Testpyramide1 Automatisierungspyramide fr das Testen von Software: relativer Anteil der (Bild 1) dargestellt.Teststufen [1] Da einzelne Komponenten nicht vom Tester direkt stimuliert werden knnen, ergibt sich die Automatisierung von Komponenten- undMED engineering 9-10 2012 48 Internet-PDF-Datei. Diese PDF Datei enthlt das Recht zur unbeschrnkten Intranet- und Internetnutzung, sowie zur Verbreitung ber elektronische Verteiler. Eine Verbreitung in gedruckter Form ist mit dieser PDF-Datei nicht gestattet. 2. 2 Automatisierte Systemtests erzeugen zwar Aufwand, dafr entdeckt man Fehler frher und verkrzt die EntwicklungszeitIntegrationstests fast zwangslufig und stellt im Allgemeinen kei-Die formelle Verifizierung besteht oft aus einer groen Anzahl ma-ne Herausforderung dar. Anders ist es mit Systemtests: Sptes-nuell durchgefhrter Systemtests. Ein Fehlschlag von einem odertens hier mssen sinnvolle Tests die Hardwareschnittstellen des mehreren Tests bei der formellen Verifizierung ist eine teure Sa-Systems stimulieren und beobachten. Die Messtechnik, die sp- che. Der Fehler muss behoben und danach smtliche Verifizie-ter in der Produktion fr funktionale Tests verwendet wird, kannrungstests wiederholt werden. Diese Schleife wird so lange durch-zum Beispiel auch fr die Automatisierung von Systemtests ge- laufen, bis keine Fehler mehr auftreten. Ein mehrfaches Durchlau-nutzt werden. Man sollte aber nicht versuchen, alle Systemtests fen der Schleife hat groe Auswirkungen auf die Einhaltung vonzu automatisieren. Bewhrt hat sich die 80/20-Daumenregel.Terminen und Budgets. Verifizierungstests haben daher grund-Bei der Gestaltung der Testskripte fr automatisierte Systemtests stzlich einen anderen Charakter als entwicklungsbegleitendeist eine gesunde Mischung aus kurzen und langen Tests empfeh- Tests.lenswert. Kurze Testskripte lassen sich einfacher entwickeln undUm auch Verifizierungstests zu automatisieren, muss die Testinfra-ndern. Auerdem werden Fehler leichter gefunden, gleich ob sie struktur validiert werden. Beim Entwurf der Testinfrastruktur soll-im Prfling, 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,dafr entdeckt man Automatisierte Tests Fehler frher und ver- schlieen Bedienfehler aus krzt die Entwick-lungszeit. Die Tester-gebnisse sind zuverlssiger, da Bedienfehler ausgeschlossen wer-den knnen. Ein Fehlschlag bei den Freigabetests wird unwahr-scheinlich, da die meisten Systemtests permanent laufen.Automatisierte Tests bentigen Schnittstellen, ber die der Prf-ling stimuliert (Point of Control, PoC) und berwacht (Point of Ob-servation, PoO) wird. Die geschickte Wahl von PoC und PoO be-stimmt, wie aufwndig die Implementation der Tests ist, wieschnell sie ablaufen und ob sie auch bei eigentlich irrelevanten n-derungen am Prfling berarbeitet werden mssen. Beim Reviewvon Designdokumenten sollte das Testteam daher auf die Test-Bild 2: Dr. Georg Molter, Zhlke Engineering GmbHbarkeit achten, also berlegen, wie das System oder die Kompo-nente stimuliert und das Verhalten berwacht werden kann. Ambesten wird bereits beimArchitekturentwurf eineTeststrategie entworfen Kontaktund die PoOs und PoCs fest-legt. Die Testbarkeit der Ar- Zhlke Engineering GmbHchitektur ist ein Hebel, der65760 Eschborndie Kosten automatisierterTel. +49 (0)6196 777540Fax +49 (0)6196 77754-54Systemtests immens sen- www.zuehlke.comken oder erhhen kann.MED engineering 9-10 2012 www.med-eng.de 49Internet-PDF-Datei. Diese PDF Datei enthlt das Recht zur unbeschrnkten Intranet- und Internetnutzung, sowie zurVerbreitung ber elektronische Verteiler. Eine Verbreitung in gedruckter Form ist mit dieser PDF-Datei nicht gestattet. 3. MED Informatik Softwaretests 3 Reviews sind keine sinnlose Pflichtbung. Je kritischer ein Doku- ment oder ein Code ist, umso intensiver sollte der Re- view sein te schon an die sptere Validie-lich die Kosten fr die Lizenzierung undrung gedacht werden. Eine Infra- Konfiguration des Werkzeugs entstehen.struktur fr automatisierte TestsOft wird die werkzeuggesttzte Analyse auf diekann Komponenten enthalten, dieberprfung der Einhaltung von Kodierrichtlinien wiedie Erstellung der Testflle und die MISRA-C [2] beschrnkt. Stattdessen sollten unbedingt auch der Kon-Untersuchung von Fehlern erleich-trollfluss und der Datenfluss auf Anomalien untersucht werden. Beitern. Solche Komponenten werdender Verwendung entsprechender Werkzeuge kommt es immer wie-aber fr die Verifizierungstests nicht der zu einer Hufung von Fehlmeldungen, die dann stoisch unter-bentigt und brauchen nicht vali-drckt werden. Das produziert Aufwand, und die Ergebnisse derdiert zu werden, wenn sie bei Verifi-Analyse sind nicht sozierungstests entfernt werden kn- aussagekrftig. Statt-Werkzeuggesttzte Analysenen. Durch einen geschickten Ent-dessen sollte ein Ex- ergnzt die Fehlersuchewurf der Testinfrastruktur lsst sichperte fr das Werk-also der Validierungsaufwand redu- zeug hinzugezogen werden, der die Ursache findet und behebt, seizieren. Sicherlich wird man nichtes bei der Konfiguration des Werkzeugs oder beim Programmierstil alle Verifizierungstests automa-der Entwickler.tisieren. Wenn aber die Mehr-Werkzeuggesttzte Analyse und automatisierte Tests sollten per- zahl automatisiert ist, kn-manent und von Beginn der Kodierung an laufen, um Entwicklernnen sie schon entwick- so frh wie mglich Fehler zu melden. Hier bietet sich ein Continu-lungsbegleitend re-ous Integration Server an. Statische Tests nur zum Ende der Imple- Bild 3: Dr. Georg Molter, Zhlke Engineering GmbH; BUGs: Fotoliagelmig ausgefhrtmentationsphase sind nicht sinnvoll, weil die Fehler viel zu spt ent-werden. Damit wird deckt werden. Problematische Idiome haben sich dann im Codedas Ergebnis der Ve- schon stark verbreitet. Der Testaufwand sollte nicht gleichmigrifizierung vorhersag- ber alle Komponenten des Systems oder alle Anforderungen an bar und ein Durchfallen das System verteilt werden. Wichtigere Komponenten oder Kompo- unwahrscheinlich. nenten, die beispielsweise aufgrund ihrer hohen Komplexitt mehr Fr die Fehlersuche eignen sich Fehler enthalten knnten und wichtigere Anforderungen sollten in-nicht nur dynamische Tests. Be-tensiver getestet werden.stimmte Fehlerklassen werden Bugs sind gesellige Tierchen. Wenn in einer Komponente Fehler ge-durch eine werkzeuggesttzte funden wurden, verstecken sich in ihr wahrscheinlich noch mehrAnalyse schneller gefunden. Inner- Fehler. Die Testintensitt der Komponenten sollte daher flexibel an-halb von Minuten kann die gesam- gepasst werden, um den Testaufwand nicht auf die fehlerarmente Code-Basis vollstndig unter- Komponenten zu verschwenden.sucht werden, nur mit dem Werk-Auch die Herleitung von Testfllen ist gut zu berlegen, um denzeug und ohne Infrastruktur. Ledig-grtmglichen Nutzen pro Testfall zu erzielen. Allein die Abde- MED engineering 9-10 201250Internet-PDF-Datei. Diese PDF Datei enthlt das Recht zur unbeschrnkten Intranet- und Internetnutzung, sowie zurVerbreitung ber elektronische Verteiler. Eine Verbreitung in gedruckter Form ist mit dieser PDF-Datei nicht gestattet. 4. tetd eube ch Da as entli zeh s bede W eig .1? n u fun Komp tet, vo @ 0 V1 ktioonMD110172nier nentewww.med-eng.det ein n e.ckung des Kontrollflusses eines getesteten Codes ist kein geeig-wie werkzeuggesttzte statische Analyse und Reviews ein. Derneter Mastab fr die Testtiefe. Auerdem muss das zustandsba-Testaufwand wird nicht gleichmig, sondern nach erwartetersierte Verhalten und das Verhalten bei unterschiedlichen Einga- Fehlerrate und Prioritt der Anforderungen ber die Komponen-bedaten bercksichtigt werden. Dazu existieren verschiedene sys-ten sowie entsprechend der Testpyramide auf die Teststufen ver-tematische Vorgehensweisen, nach denen man die ntzlichsten teilt. Der Testfallentwurf verwendet systematische Verfahren zurTestflle auswhlt, beispielsweise Zustandsbaum, quivalenzklas-Herleitung der Testflle.sen- und Grenzwertanalyse, um nur die wichtigsten zu nennen.Auch die Durchfhrung von Tests sollte so frh wie mglich begin-Reviews haben den Vorteil, zu jedem Zeitpunkt in der Entwicklungnen und auf allen Teststufen inklusive Systemtest automatisiert wer-fr beliebige Dokumente wie auch fr Code durchgefhrt werden den. Die geschickte Auswahl der zu automatisierenden Tests und diezu knnen. Sie sind keine Pflichtbung, sondern ein probates Mit- Gestaltung der Testskripte erfordern eine gewisse Erfahrung. Zumtel, um kostengnstig und frher als mit dynamischen Tests Feh- Abschluss des Testens sollten Verbesserungspotentiale untersuchtler zu finden. Die Effektivitt von Reviews lsst sich steigern, in-werden. In iterativ-inkrementell arbeitenden Projekten wird die-dem die Zeit und Aufmerksamkeit der verfgbaren Reviewer op-ser Rckblick oft Retrospektive genannt und sollte fr das Testentimal genutzt wird. Je kritischer ein Dokument oder Code, desto genauso wie fr die Entwicklung gelten.intensiver sollte der Review sein. Vor dem Code-Review sollten zu-erst Anomalien und Abweichungen, die die werkzeuggesttzteLiteraturAnalyse gefunden hat, bereinigt werden. [1] The Tar Pit, Test Automation Pyramid, http://blog.goneopen.com/2010/08/test-automation-pyramid-review/Die agile Entwicklung hat Wege aufgezeigt, Software effizienter zu[2] MISRA-C:2004 Guidelines for the use of the C language in critical systems,testen. Mit dem entsprechenden Expertenwissen lassen sich diese http://www.misra.org.uk/Erkenntnisse auf die Entwicklung von Medizinprodukten bertra-[3] International Software Testing Qualifications Board, http://istqb.orggen. Die allgemeine Grundlage bildet der Lehrplan des ISTQB [3]. Zeitist kostbar. Daher sollten die Testaktivitten 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-Matthias Kraazte Hebel fr effizienteres Testen. Eine gute Teststrategie setzt ne-ist Lead Software Architect bei Zhlke in Eschborn.ben Systemtests auch Komponenten- und Integrationstests so- matthias.kraaz@zuehlke.comMED engineering 9-10 2012www.med-eng.de51Internet-PDF-Datei. Diese PDF Datei enthlt das Recht zur unbeschrnkten Intranet- und Internetnutzung, sowie zurVerbreitung ber elektronische Verteiler. Eine Verbreitung in gedruckter Form ist mit dieser PDF-Datei nicht gestattet.