Software-Entwicklung
FDA empfiehlt automatisierte Tools für den Software-Test
Fortsetzung des Artikels von Teil 1
Testwerkzeuge
Bild 3 zeigt verschiedene Teststrategien im Softwareentwicklungs-Lebenszyklus. Zwar empfiehlt die FDA, mit dem Modultest zu beginnen, dies ist aber manchmal nicht machbar. Besonders bei der Zertifizierung einer älteren Anwendung (Legacy Applications) wäre es zu aufwendig, für jedes einzelne Modul einen Modultest durchzuführen. Ein anderer gangbarer Weg ist, mit einem Systemtest zu beginnen und den Modultest auf solche Module zu beschränken, die beim Systemtest nicht mit ausreichender Fehlerabdeckung geprüft wurden.
Viele automatisierte Testwerkzeuge unterstützen sowohl den Bottom-up- wie auch den Top-down-Ansatz. Dabei lassen sich Informationen über die Codeabdeckung zwischen den verschiedenen Testphasen austauschen.
Durch Nutzung des Quellcodes mit einem automatischen Testwerkzeug, wie in Bild 4 gezeigt, kann man Codeabdeckungs-Informationen aus dem Systemtest archivieren.
Aus Sicht der FDA ist »das erwartete Ergebnis ein zentrales Element eines Softwaretests«. Dabei ist es nicht nur wichtig, dass ein automatisiertes Testwerkzeug die einfache Definition erwarteter Werte für einen Testfall erlaubt.
Manche Tools lassen sich sogar mit einem Werkzeug zur Verwaltung von Anforderungen (Requirements) beziehungsweise mit einem Lebenszyklus-Verwaltungswerkzeug für Anwendungen integrieren, sodass sich die erwarteten Werte entsprechend der Anforderungen ermitteln lassen (Bild 5). Nach den GPoSV-Empfehlungen sollten die erwarteten Werte »aus der entsprechenden, zuvor festgelegten Definition oder Spezifikation abgeleitet werden«.
Struktureller oder White-Box-Test
Manche Qualitätssicherungs-Strategien konzentrieren sich auf die Verifikation von Anforderungen und sind vollständig unabhängig vom Quellcode; demgegenüber empfiehlt die FDA ausdrücklich einen strukturellen Test. In der GPoSV heißt es deswegen: »Ein Software-Produkt sollte mit Testfällen überprüft werden, die aus der internen Struktur der Software abgeleitet sind«, »Testfälle sollten auf Wissen beruhen, das aus dem Quellcode abgeleitet wurde« und »ein struktureller Test lässt sich anhand von Bewertungsmaßstäben auswerten, die man meist als »Prüfabdeckung« bezeichnet«.
Diese Empfehlungen verweisen auf eine Publikation über den strukturellen Test auf Grundlage einer Basis-Path-Analyse anhand des Bewertungsmaßstabs der zyklomatischen Komplexität nach McCabe.
Automatisierte Testwerkzeuge können nützlich sein, um die Codeabdeckung zu bestimmen, da sie unter anderem den Code für die Ermittlung der Codeabdeckungsinformationen aus dem Modul-, Integrations- und Systemtest ableiten.
Außerdem können automatisierte Testwerkzeuge durch eine Analyse des Quellcodes selbstständig Testfälle generieren, die bei Ausführung das gewünschte Maß an Codeabdeckung (z.B. Statement-, Verzweigungs- und Decision-Abdeckung) erzielen (Bild 6). Solche automatisch generierten Testfälle enthalten keine erwarteten Werte – diese sollte man manuell auf der Basis von Anforderungen eingeben und nicht automatisch auf anhand des Codes ermitteln.
Die automatisch auf der Grundlage von Basis-Paths erzeugten Testfälle bieten oft eine hohe Statement-Prüfabdeckung (Basis-Paths sind jeweils unabhängige Pfade durch den Kontrollfluss des Programms).Die Anzahl der Testfälle entspricht der zyklomatischen Komplexität des Programms (auch bekannt als Komplexitätsmaß nach McCabe). Auf Grundlage dieser Analyse kann das Werkzeug automatisch Testfälle generieren, die bei ihrer Ausführung eine Statement- und Verzweigungs-Codeabdeckung von 100% erreichen. Zusätzlich wird die Komplexität der Funktion ermittelt.
Die Komplexität und die zusammengefassten Codeabdeckungs-Informationen aus allen Testfällen lassen sich mit einem automatisierten Testwerkzeug ermitteln (Bild 7).
Funktionaler oder Black-Box-Test
Zusätzlich empfiehlt die FDA auch, dass »ein Softwareprodukt anhand von Testfällen überprüft werden sollte, die aus deren externer Spezifikation abgeleitet wurden«. Die GPoSV-Empfehlungen erwähnen die folgenden Arten von funktionellen Tests:
- Normalfall – eine Überprüfung mit den üblichen Eingangsdaten ist erforderlich,
- Output-Forcing – ausgewählte (oder alle) Software-Ausgangszustände werden durch den Test erzeugt,
- Robustheit – unerwartete oder ungültige Eingangsdaten, Partitionierung nach Äquivalenzklassen, Grenzwertanalyse und die Ermittlung von Sonderfällen (»Error Guessing«) und
- Kombination von Eingangszuständen – Berücksichtigung einer Kombination der oben ermittelten Eingangszustände.
Automatisierte Testwerkzeuge können den Wertebereich der Parameter einer Funktionsschnittstelle untersuchen. Anhand dieser Analysen lassen sich automatisch Testfälle erzeugen, welche die Funktion mit <<MIN>>-1, <<MIN>> oder <<MAX>> und <<MAX>>+1 stimulieren (Dabei ist zu beachten, dass in manchen Fällen aufgrund eines Datenüberlaufs <<MIN>>-1 gleichbedeutend mit <<MAX>>, und <<MAX>>+1 gleichbedeutend mit <<MIN>> ist. Andererseits können diese Testparameter in Situationen sinnvoll sein, bei denen der Typenbereich unabhängig von den benutzten Bits eingeschränkt ist). Eine Funktionsschnittstelle lässt sich auch mit einer Reihe von Werten zwischen <<MIN>> und <<MAX>> oder zwischen <<MIN>>-1 und <<MAX>>+1 testen, wobei diese Routine entweder einmal pro Schritt oder mit allen Kombinationen der Eingangswerte ausgeführt werden.
Bild 8 zeigt einen automatisch generierten Testfall, der die Funktion mit einem Satz von Werten innerhalb der zulässigen Grenzen stimuliert. Die Schrittgröße (Anzahl der Partitionen) ist konfigurierbar; ebenfalls lässt sich konfigurieren, ob die Funktion einmal pro Schritt oder mit allen möglichen Kombinationen aufgerufen werden soll. Beim Kombinationstest sollte man allerdings vorsichtig vorgehen, da die Anzahl der Testfälle ansonsten exponentiell zunimmt.
Im Zusammenhang mit funktionellen Tests erwähnen die GPoSV-Empfehlungen auch statistische Tests. Dabei sollen zufällige Werte sowie Werte »auf der Basis eines Betriebsprofils« für die Verifikation des Quellcode-Funktionsumfangs in Bezug auf die Anforderungen verwendet werden. Die GPoSV-Empfehlungen erwähnen dabei, dass »große Mengen an Testdaten erzeugt werden«. Ein Softwareentwickler dürfte eine Funktion mit einer großen Menge an Testdaten wohl kaum manuell überprüfen. Mit automatisierten Testwerkzeugen lassen sich zahlreiche Testfälle zum Beispiel über einen Import von Eingangswerten sowie erwarteten Ausgangswerten aus einer CSV-Datei erstellen. Die CSV-Datei lässt sich entweder über ein modellgestütztes Generierungskonzept für Testwerte oder – wie von der FDA vorgeschlagen – anhand eines Betriebsprofils erzeugen. Die Spalten der CSV-Datei lassen sich mit den Datenfeldern für die Eingangswerte und die erwarteten Ausgangswerte in der Kalkulationstabelle für die Parameterschnittstelle verknüpfen. Anhand der Werte in der CSV-Datei lassen sich zahlreiche Testfälle automatisch und ohne die Notwendigkeit manueller Eingriffe erstellen, ausführen und im Vergleich zu den erwarteten Ausgangszuständen verifizieren.
Regressionstests
Die FDA erwähnt in den GPoSV-Empfehlungen auch Softwareänderungen und wie man mit diesen in Bezug auf Tests umgeht. Solche Änderungen können aus unterschiedlichen Gründen notwendig werden: Fehlerkorrekturen, neue oder veränderte Anforderungen, Designmodifikationen (effektivere oder effizientere Implementierung), kontinuierliche Integration oder TDD (Test Driven Development).
Die FDA erwähnt Regressionstests ausdrücklich als eine wichtige Möglichkeit, mit der Softwareentwickler das Risiko der Einführung unerwünschter Nebeneffekte bei Codeveränderungen an der Software minimieren können: »Regressionstests (die wiederholte Ausführung von Testfällen, die ein Programm früher schon einmal korrekt ausgeführt hat, und der Vergleich der aktuellen Ergebnisse zu früheren Ergebnissen, um unbeabsichtigte Auswirkungen einer Softwareänderung zu ermitteln) sollen ausgeführt werden, um sicherzustellen, dass eine Veränderung keine Probleme an einer anderen Stelle im Softwareprodukt verursacht«.
Softwareentwickler wollen Regressionstests nicht manuell ausführen. Ein zuvor erzeugter Testfall sollte sich ohne jeglichen manuellen Eingriff automatisch ausführen lassen. Automatisierte Testwerkzeuge können Regressionstests selbsttätig abwickeln, zum Beispiel jede Nacht oder unmittelbar, wenn eine Codeveränderung in die Codebasis eingetragen wird.
Die enge Verknüpfung einer Softwareänderung mit einer neu eingeführten Fehlfunktion ist entscheidend, da Arbeitsaufwand und Kosten für die Korrektur eines Fehlers stark zunehmen, je mehr Zeit bis zur Erkennung und Behebung vergeht. Daher sind Regressionstests bei automatisierten Testwerkzeugen von zentraler Bedeutung.
Qualität von Testwerkzeugen
Die GPoSV-Empfehlungen fordern, dass »Software-Testwerkzeuge ein Qualitätsniveau bieten sollten, das nicht geringer sein darf als das des Softwareprodukts, das damit entwickelt wird. Entsprechende Dokumentation sollte mit einem Nachweis der Validierung dieser Softwarewerkzeuge für den beabsichtigten Einsatz gepflegt werden«.
Einige Software-Testwerkzeugen haben einen formalen Zertifizierungsprozess durchlaufen und wurden zum Beispiel nach IEC 61508 oder ISO 26262 zertifiziert. Solche Werkzeuge werden mit folgender Dokumentation geliefert:
- Ein Zertifikat der Prüforganisation als Beleg für die Zertifizierung.
- Anforderungen für den Betrieb des Werkzeugs (TOR, Tool Operational Requirements): Dieses Dokument enthält überprüfbare Anforderungen für das Werkzeug oder den zu überprüfenden Übersetzer zusammen mit Informationen über die Arbeitsumgebung des Projekts, welche die vom Werkzeug gelieferten Ergebnisse beeinflussen können (z.B. Mikroprozessor-Architektur).
- Werkzeug-Qualifizierungsdaten (TQD, Tool Qualification Data): Dieses Dokument beschreibt die Testdaten und die Ergebnisse aus der Serie der Qualifikationstests, die zur Verifikation aller Anforderungen in den TOR unter Nutzung der Arbeitsumgebung des Projekts erforderlich waren.
- Compliance-Analyse nach IEC 61508 oder ISO 26262: Diese Informationen werden typischerweise in einem Workflow-Handbuch erfasst, das den Einsatz des Werkzeugs innerhalb vorgegebener Grenzbedingungen beschreibt. Dies gewährleistet, dass die damit erzeugten Ergebnisse die Erfüllung der Norm hinreichend belegen.
Testwerkzeuge richtig evaluieren
Zur Erfüllung der Vorschläge in den GPoSV-Empfehlungen regt das FDA den Einsatz automatisierter Testwerkzeuge an. Dabei ist die Auswahl des richtigen Werkzeugs ein wichtiger Prozess für ein Unternehmen, da dieses Werkzeug starke Auswirkungen auf die täglichen Arbeitsabläufe hat. Damit sich diese Investition schnell rentiert, sollte ein Unternehmen Folgendes tun:
- Es sollte die infrage kommenden Werkzeuge mit Code evaluieren, der repräsentativ für den Programmcode des Unternehmens ist.
- Es sollte diese Werkzeuge mit den gleichen Tools überprüfen, die auch für reale Projekte im Hause verwendet werden.
- Man sollte sich bei langjährigen Kunden des Anbieters informieren und diese fragen, ob sie mit dem Anbieter zufrieden sind.
- Überprüfen Sie die Fähigkeiten des technischen Supports des Toolanbieters. Stellen Sie den Support auf die Probe, indem Sie direkt Fragen an das Support-Team stellen, und nicht nur an den Vertriebsberater.
- Untersuchen Sie, wie automatisiert, wie bedienerfreundlich und wie umfassend das Werkzeug und die Produktunterstützung sind.
Um mehr über die Entwicklung und das Testen von Software für medizinische Geräte zu erfahren, sei auf eine Gruppe auf LinkedIn [4] hingewiesen.
Über den Autor:
Ingo Nickles ist Field Applicartion Engineer bei Vector Software.
- FDA empfiehlt automatisierte Tools für den Software-Test
- Testwerkzeuge
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
