• Share
  • Email
  • Embed
  • Like
  • Private Content
Wirtschaftlich testen: Softwaretests in der Medizintechnik (Matthias Kraaz)
 

Wirtschaftlich testen: Softwaretests in der Medizintechnik (Matthias Kraaz)

on

  • 708 views

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

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

Artikel in der MEDengineering 9-10, 2012 von Matthias Kraaz. Kontakt: http://xing.to/kraaz

Statistics

Views

Total Views
708
Views on SlideShare
707
Embed Views
1

Actions

Likes
0
Downloads
4
Comments
0

1 Embed 1

https://twitter.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

    • MED Informatik Softwaretests 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 V iele aktive Medizinprodukte sich so frühzeitig reagieren, und böse Überraschungen lassen sich enthalten Software, und bei der formellen Verifizierung vermeiden. Eine solche Vorgehens- Software enthält normaler- weise erhöht zunächst den Aufwand, amortisiert sich jedoch schnell. weise Fehler. Daher verlangen Systemtests sind aufwändig in der Erstellung und Durchführung. Gesetzgeber umfangreiche Tests Schlägt ein Test fehl, ist die Lokalisierung der Ursache ebenfalls sich von Software und System. Häufig aufwändig. Zudem kann mit Systemtests erst begonnen werden, lo hnt en vor- werden während der Produktent- wenn ein testbares Sys- »Es nent .« wicklung unsystematisch zu allen tem verfügbar ist. Daher Frühes Testen vermeidet o mp testenKo zu Systemanforderungen Testfälle spe- sind auch Komponenten- Überraschungen zifiziert und ausgeführt, sobald die und Integrationstests rat- Entwicklung abgeschlossen ist. Es sam, da viel früher getestet werden kann. Fehler werden so früher werden also nur manuelle System- gefunden und behoben. Beim Komponententest werden die kleins- tests durchgeführt. Effizienter ist es,ten, nicht weiter sinnvoll zerlegbaren Einheiten eines Systems ge- schon während der Entwicklung zu testet. Sie werden oft auch als Unit-Tests bezeichnet. Tauchen hier testen und die Entwickler mit früh- Fehler auf, lässt sich mit geringem Aufwand die Ursache finden und zeitigen Fehlerberichten zu unter- beheben. Gleichzeitig ist die Stimulation des Prüflings wesentlich stützen. Auf Qualitätsprobleme lässt einfacher, was den Aufwand für die Testerstellung und die Laufzeit der Tests reduziert, die Testabdeckung aber erhöht. 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 auch System- eher aus dem Zusammenspiel der Kompo- tests nenten und nicht aus intrinsischen Fehlern der Komponenten selbst. Mit diesem Wissen lässt sich die Ursache wiederum schneller fin- Integrationstests den und beheben. Komponenten- und Inte- grationstest reduzieren daher die Anzahl der teuren Systemtests, ohne die Zuverlässigkeit der Testergebnisse zu mindern. Aus dieser Vorgehensweise ergeben sich sehr viele Kom- Komponententests ponententests, viele Integrationstests, aber wesentlich weniger Systemtests. In der agilen Community wird der Aufbau der Teststufen aufeinander und das Zahlenverhältnis der © MED engineering Tests durch die sogenannte Testpyramide1 Automatisierungspyramide für das Testen von Software: relativer Anteil der (Bild 1) dargestellt.Teststufen [1] Da einzelne Komponenten nicht vom Tester direkt stimuliert werden können, ergibt sich die Automatisierung von Komponenten- und MED engineering 9-10 2012 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.
    • 2 Automatisierte Systemtests erzeugen zwar Aufwand, dafür entdeckt man Fehler früher und verkürzt die Entwicklungszeit Integrationstests fast zwangsläufig und stellt im Allgemeinen kei- Die formelle Verifizierung besteht oft aus einer großen Anzahl ma- ne Herausforderung dar. Anders ist es mit Systemtests: Spätes- nuell durchgeführter Systemtests. Ein Fehlschlag von einem oder tens hier müssen 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 sämtliche Verifizie- ter in der Produktion für funktionale Tests verwendet wird, kann rungstests wiederholt werden. Diese Schleife wird so lange durch- zum Beispiel auch für 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 große Auswirkungen auf die Einhaltung von zu automatisieren. Bewährt hat sich die 80/20-Daumenregel. Terminen und Budgets. Verifizierungstests haben daher grund- Bei der Gestaltung der Testskripte für automatisierte Systemtests sätzlich einen anderen Charakter als entwicklungsbegleitende ist eine gesunde Mischung aus kurzen und langen Tests empfeh- Tests. lenswert. Kurze Testskripte lassen sich einfacher entwickeln und Um auch Verifizierungstests zu automatisieren, muss die Testinfra- ändern. Außerdem werden Fehler leichter gefunden, gleich ob sie struktur validiert werden. Beim Entwurf der Testinfrastruktur soll- im 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 zu quantifizieren. Der Aufbau der Infrastruktur kostet Zeit und Geld, dafür entdeckt man Automatisierte Tests Fehler früher und ver- schließen Bedienfehler aus 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, wie schnell sie ablaufen und ob sie auch bei eigentlich irrelevanten Än- derungen am Prüfling überarbeitet werden müssen. Beim Review von Designdokumenten sollte das Testteam daher auf die Test-Bild 2: Dr. Georg Molter, Zühlke Engineering GmbH barkeit achten, also überlegen, wie das System oder die Kompo- nente stimuliert und das Verhalten überwacht werden kann. Am besten wird bereits beim Architekturentwurf eine Teststrategie entworfen Kontakt und die PoOs und PoCs fest- legt. Die Testbarkeit der Ar- Zühlke Engineering GmbH chitektur ist ein Hebel, der 65760 Eschborn die Kosten automatisierter Tel. +49 (0)6196 777540 Fax +49 (0)6196 77754-54 Systemtests immens sen- www.zuehlke.com ken oder erhöhen kann. MED engineering 9-10 2012 www.med-eng.de 49 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.
    • MED Informatik Softwaretests 3 Reviews sind keine sinnlose Pflichtübung. Je kritischer ein Doku- ment oder ein Code ist, umso intensiver sollte der Re- view sein te schon an die spätere Validie- lich die Kosten für die Lizenzierung und rung gedacht werden. Eine Infra- Konfiguration des Werkzeugs entstehen. struktur für automatisierte Tests Oft wird die werkzeuggestützte Analyse auf die kann Komponenten enthalten, die Überprüfung der Einhaltung von Kodierrichtlinien wie die Erstellung der Testfälle und die MISRA-C [2] beschränkt. Stattdessen sollten unbedingt auch der Kon- Untersuchung von Fehlern erleich- trollfluss und der Datenfluss auf Anomalien untersucht werden. Bei tern. Solche Komponenten werden der Verwendung entsprechender Werkzeuge kommt es immer wie- aber für die Verifizierungstests nicht der zu einer Häufung von Fehlmeldungen, die dann stoisch unter- benötigt und brauchen nicht vali- drückt werden. Das produziert Aufwand, und die Ergebnisse der diert zu werden, wenn sie bei Verifi- Analyse sind nicht so zierungstests entfernt werden kön- aussagekräftig. Statt- Werkzeuggestützte Analyse nen. Durch einen geschickten Ent- dessen sollte ein Ex- ergänzt die Fehlersuche wurf der Testinfrastruktur lässt sich perte für das Werk- also der Validierungsaufwand redu- zeug hinzugezogen werden, der die Ursache findet und behebt, sei zieren. Sicherlich wird man nicht es bei der Konfiguration des Werkzeugs oder beim Programmierstil alle Verifizierungstests automa- der Entwickler. tisieren. Wenn aber die Mehr- Werkzeuggestützte Analyse und automatisierte Tests sollten per- zahl automatisiert ist, kön- manent und von Beginn der Kodierung an laufen, um Entwicklern nen sie schon entwick- so früh wie möglich 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, Zühlke Engineering GmbH; BUGs: Fotolia gelmäßig ausgeführt mentationsphase sind nicht sinnvoll, weil die Fehler viel zu spät ent- werden. Damit wird deckt werden. Problematische Idiome haben sich dann im Code das Ergebnis der Ve- schon stark verbreitet. Der Testaufwand sollte nicht gleichmäßig rifizierung 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 Komplexität mehr Für die Fehlersuche eignen sich Fehler enthalten könnten 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 werkzeuggestützte funden wurden, verstecken sich in ihr wahrscheinlich noch mehr Analyse schneller gefunden. Inner- Fehler. Die Testintensität der Komponenten sollte daher flexibel an- halb von Minuten kann die gesam- gepasst werden, um den Testaufwand nicht auf die fehlerarmen te Code-Basis vollständig unter- Komponenten zu verschwenden. sucht werden, nur mit dem Werk- Auch die Herleitung von Testfällen ist gut zu überlegen, um den zeug und ohne Infrastruktur. Ledig- größtmöglichen Nutzen pro Testfall zu erzielen. Allein die Abde- MED engineering 9-10 2012 50Internet-PDF-Datei. Diese PDF Datei enthält das Recht zur unbeschränkten Intranet- und Internetnutzung, sowie zurVerbreitung über elektronische Verteiler. Eine Verbreitung in gedruckter Form ist mit dieser PDF-Datei nicht gestattet.
    • tet d eu be ch »Da as entli « zeh s bede »W eig .1? n u fun Komp tet, vo @ 0 V1 ktio o n MD110172 nier nente www.med-eng.de t ein n e.«ckung des Kontrollflusses eines getesteten Codes ist kein geeig- wie werkzeuggestützte statische Analyse und Reviews ein. Derneter Maßstab für die Testtiefe. Außerdem muss das zustandsba- Testaufwand wird nicht gleichmäßig, sondern nach erwartetersierte Verhalten und das Verhalten bei unterschiedlichen Einga- Fehlerrate und Priorität der Anforderungen über die Komponen-bedaten berücksichtigt werden. Dazu existieren verschiedene sys- ten sowie entsprechend der Testpyramide auf die Teststufen ver-tematische Vorgehensweisen, nach denen man die nützlichsten teilt. Der Testfallentwurf verwendet systematische Verfahren zurTestfälle auswählt, beispielsweise Zustandsbaum, Äquivalenzklas- Herleitung der Testfälle.sen- und Grenzwertanalyse, um nur die wichtigsten zu nennen. Auch die Durchführung von Tests sollte so früh wie möglich begin-Reviews haben den Vorteil, zu jedem Zeitpunkt in der Entwicklung nen und auf allen Teststufen inklusive Systemtest automatisiert wer-für beliebige Dokumente wie auch für Code durchgeführt werden den. Die geschickte Auswahl der zu automatisierenden Tests und diezu können. Sie sind keine Pflichtübung, sondern ein probates Mit- Gestaltung der Testskripte erfordern eine gewisse Erfahrung. Zumtel, um kostengünstig und früher als mit dynamischen Tests Feh- Abschluss des Testens sollten Verbesserungspotentiale untersuchtler zu finden. Die Effektivität von Reviews lässt sich steigern, in- werden. In iterativ-inkrementell arbeitenden Projekten wird die-dem die Zeit und Aufmerksamkeit der verfügbaren Reviewer op- ser Rückblick oft Retrospektive genannt und sollte für das Testentimal genutzt wird. Je kritischer ein Dokument oder Code, desto genauso wie für die Entwicklung gelten.intensiver sollte der Review sein. Vor dem Code-Review sollten zu-erst Anomalien und Abweichungen, die die werkzeuggestützte LiteraturAnalyse 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 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öß- Matthias Kraazte Hebel für effizienteres Testen. Eine gute Teststrategie setzt ne- ist Lead Software Architect bei Zühlke in Eschborn.ben Systemtests auch Komponenten- und Integrationstests so- matthias.kraaz@zuehlke.comMED engineering 9-10 2012 www.med-eng.de 51 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.