Aufrufe
vor 3 Jahren

Wirtschaftlich testen - Softwaretests in der Medizintechnik - Zühlke

Wirtschaftlich testen - Softwaretests in der Medizintechnik - Zühlke

2 Automatisierte

2 Automatisierte Systemtests erzeugen zwar Aufwand, dafür entdeckt man Fehler früher und verkürzt die Entwicklungszeit Bild 2: Dr. Georg Molter, Zühlke Engineering GmbH Integrationstests fast zwangsläufig und stellt im Allgemeinen keine Herausforderung dar. Anders ist es mit Systemtests: Spätestens hier müssen sinnvolle Tests die Hardwareschnittstellen des Systems stimulieren und beobachten. Die Messtechnik, die später in der Produktion für funktionale Tests verwendet wird, kann zum Beispiel auch für die Automatisierung von Systemtests genutzt werden. Man sollte aber nicht versuchen, alle Systemtests zu automatisieren. Bewährt hat sich die 80/20-Daumenregel. Bei der Gestaltung der Testskripte für automatisierte Systemtests ist eine gesunde Mischung aus kurzen und langen Tests empfehlenswert. Kurze Testskripte lassen sich einfacher entwickeln und ändern. Außerdem werden Fehler leichter gefunden, gleich ob sie im Prüfling, in der Testinfrastruktur oder im Testskript liegen. Manche Fehler werden aber erst durch lange Testskripte oder aufeinander aufbauende kurze Testskripte entdeckt. Der Vorteil automatisierter Systemtests (Bild 2) ist schwierig zu quantifizieren. Der Aufbau der Infrastruktur kostet Zeit und Geld, Automatisierte Tests schließen Bedienfehler aus dafür entdeckt man Fehler früher und verkürzt die Entwicklungszeit. Die Testergebnisse sind zuverlässiger, da Bedienfehler ausgeschlossen werden können. Ein Fehlschlag bei den Freigabetests wird unwahrscheinlich, da die meisten Systemtests permanent laufen. Automatisierte Tests benötigen Schnittstellen, über die der Prüfling stimuliert (Point of Control, PoC) und überwacht (Point of Observation, PoO) wird. Die geschickte Wahl von PoC und PoO bestimmt, wie aufwändig die Implementation der Tests ist, wie schnell sie ablaufen und ob sie auch bei eigentlich irrelevanten Änderungen am Prüfling überarbeitet werden müssen. Beim Review von Designdokumenten sollte das Testteam daher auf die Testbarkeit achten, also überlegen, wie das System oder die Komponente stimuliert und das Verhalten überwacht werden kann. Am besten wird bereits beim Architekturentwurf eine Teststrategie entworfen und die PoOs und PoCs festlegt. Die Testbarkeit der Architektur ist ein Hebel, der die Kosten automatisierter Systemtests immens senken oder erhöhen kann. Kontakt Zühlke Engineering GmbH 65760 Eschborn Tel. +49 (0)6196 777540 Fax +49 (0)6196 77754-54 www.zuehlke.com Die formelle Verifizierung besteht oft aus einer großen Anzahl manuell durchgeführter Systemtests. Ein Fehlschlag von einem oder mehreren Tests bei der formellen Verifizierung ist eine teure Sache. Der Fehler muss behoben und danach sämtliche Verifizierungstests wiederholt werden. Diese Schleife wird so lange durchlaufen, bis keine Fehler mehr auftreten. Ein mehrfaches Durchlaufen der Schleife hat große Auswirkungen auf die Einhaltung von Terminen und Budgets. Verifizierungstests haben daher grundsätzlich einen anderen Charakter als entwicklungsbegleitende Tests. Um auch Verifizierungstests zu automatisieren, muss die Testinfrastruktur validiert werden. Beim Entwurf der Testinfrastruktur soll- MED engineering 9-10 2012 www.med-eng.de 49

MED Informatik Softwaretests 3 Reviews sind keine sinnlose Pflichtübung. Je kritischer ein Dokument oder ein Code ist, umso intensiver sollte der Review sein te schon an die spätere Validierung gedacht werden. Eine Infrastruktur für automatisierte Tests kann Komponenten enthalten, die die Erstellung der Testfälle und die Untersuchung von Fehlern erleichtern. Solche Komponenten werden aber für die Verifizierungstests nicht benötigt und brauchen nicht validiert zu werden, wenn sie bei Verifizierungstests entfernt werden können. Durch einen geschickten Entwurf der Testinfrastruktur lässt sich also der Validierungsaufwand reduzieren. Sicherlich wird man nicht alle Verifizierungstests automatisieren. Wenn aber die Mehrzahl automatisiert ist, können sie schon entwicklungsbegleitend regelmäßig ausgeführt werden. Damit wird das Ergebnis der Verifizierung vorhersagbar und ein Durchfallen unwahrscheinlich. Für die Fehlersuche eignen sich nicht nur dynamische Tests. Bestimmte Fehlerklassen werden durch eine werkzeuggestützte Analyse schneller gefunden. Innerhalb von Minuten kann die gesamte Code-Basis vollständig untersucht werden, nur mit dem Werkzeug und ohne Infrastruktur. Lediglich die Kosten für die Lizenzierung und Konfiguration des Werkzeugs entstehen. Oft wird die werkzeuggestützte Analyse auf die Überprüfung der Einhaltung von Kodierrichtlinien wie MISRA-C [2] beschränkt. Stattdessen sollten unbedingt auch der Kontrollfluss und der Datenfluss auf Anomalien untersucht werden. Bei der Verwendung entsprechender Werkzeuge kommt es immer wieder zu einer Häufung von Fehlmeldungen, die dann stoisch unterdrückt werden. Das produziert Aufwand, und die Ergebnisse der Werkzeuggestützte Analyse ergänzt die Fehlersuche Analyse sind nicht so aussagekräftig. Stattdessen sollte ein Experte für das Werkzeug hinzugezogen werden, der die Ursache findet und behebt, sei es bei der Konfiguration des Werkzeugs oder beim Programmierstil der Entwickler. Werkzeuggestützte Analyse und automatisierte Tests sollten permanent und von Beginn der Kodierung an laufen, um Entwicklern so früh wie möglich Fehler zu melden. Hier bietet sich ein Continuous Integration Server an. Statische Tests nur zum Ende der Implementationsphase sind nicht sinnvoll, weil die Fehler viel zu spät entdeckt werden. Problematische Idiome haben sich dann im Code schon stark verbreitet. Der Testaufwand sollte nicht gleichmäßig über alle Komponenten des Systems oder alle Anforderungen an das System verteilt werden. Wichtigere Komponenten oder Komponenten, die beispielsweise aufgrund ihrer hohen Komplexität mehr Fehler enthalten könnten und wichtigere Anforderungen sollten intensiver getestet werden. Bugs sind gesellige Tierchen. Wenn in einer Komponente Fehler gefunden wurden, verstecken sich in ihr wahrscheinlich noch mehr Fehler. Die Testintensität der Komponenten sollte daher flexibel angepasst werden, um den Testaufwand nicht auf die fehlerarmen Komponenten zu verschwenden. Auch die Herleitung von Testfällen ist gut zu überlegen, um den größtmöglichen Nutzen pro Testfall zu erzielen. Allein die Abde- Bild 3: Dr. Georg Molter, Zühlke Engineering GmbH; BUGs: Fotolia 50 MED engineering 9-10 2012

Wirtschaftlich Software Testen - Zühlke
Was bedeutet der Einstieg in die Medizintechnik für die ... - Zühlke
Schattenspiele: Kinect-Anwendungen erfolgreich testen - Zühlke
(Microsoft PowerPoint - Software Engineering in der Praxis ... - Zühlke
Basiswissen Softwaretest - Certified Tester - - German Testing Night