Testentwurfsverfahren: Die Komplexität von technischen Systemen steigt seit Jahren und ein Ende ist nicht absehbar. Der entscheidende Innovationstreiber ist dabei die Software. Sehr leistungsfähige Hardware in Kombination mit komplexer Software sind die Grundlage für Trends wie Industrie 4.0, autonomes Fahren, Smart Home und MKS Mensch-Roboter Kollaboration, um nur einige zu nennen.

Software ermöglicht heute die Realisierung von Funktionalitäten mit einer Komplexität, welche mit Elektronik oder Mechanik alleine nie denkbar war.

Allerdings steigen damit auch die potentiellen Fehler in einem System. Eine garantiert fehlerfreie Software gibt es nicht! Ein wesentlicher Grund dafür ist, dass es nicht möglich ist ein industrie-relevantes Software System vollständig zu Testen. Dies wiederum ist darin begründet, dass die Anzahl der Daten- und Kontrollflusspfade die in einer Software durchlaufen werden können, tendenziell unendlich ist. Mit diesem Hintergrund stellt der nachfolgende Beitrag gängige Testentwurfsverfahren vor und bewertet deren Stärken und Schwächen.

Überblick über die Wichtigsten Testentwurfsverfahren

Alle Testentwurfsverfahren, welche in der Industrie zur Anwendung kommen, haben das Ziel die „richtigen“ Testfälle aus der potentiell unendlich großen Menge aller Testfälle zu finden. Wie schon erwähnt, ist ein vollständiger Test, nur für trivial Software möglich.

Die Testentwurfsverfahren können wie folgt unterschieden werden:

• Spezifikationsbasiert
• Strukturbasiert
• Effizienzbasiert
• Erfahrungsbasiert
• Risikobasiert

Jede der genannten Testentwurfsverfahren trägt das Kriterium für die Auswahl der „richtigen“ Testfälle schon im Namen. Um die Testabdeckung zu erhöhen, ist es in vielen Fällen sinnvoll die Entwurfsverfahren zu kombinieren.

Spezifikationsbasiertes Testentwurfsverfahren

Spezifikationsbasierte Testentwurfsverfahren sind auch als Black-Box Test bekannt. Sie verwenden die Requirements oder die Architektur als Basis für die Erstellung der Tests. Die Erfahrung aus der praktischen Anwendung der letzten 20 Jahre zeigt, dass das spezifikationsbasierte Entwurfsverfahren das wichtigste aller Testentwurfsverfahren ist. Die Gründe dafür sind:

• Requirements ermöglichen eine systematische und nachvollziehbare Vorgehensweise beim Testen
• Die Dokumentation der Architektur eröffnet die Möglichkeit Schwachstellen des Systems systematisch durch Tests und vor allem auch Reviews zu lokalisieren
• Tests können immer nur einzelne Aspekte nachweisen. Atomare Requirements bilden dazu die ideale Voraussetzung
• Der Test weist immer eine Funktionalität des Systems nach. Die Beschreibung der Funktionalität ist die große Stärke von Requirements.
• Die systematische Identifikation der zu testenden Schnittstellen eines Systems sind für den Test essentiell wichtig. Die Dokumentation der Architektur definiert genau diese Schnittstellen.
• Schon bei der Erstellung der Requirements können wichtige Fragen zum späteren Test berücksichtigt werden. Requirements ermöglichen damit eine maximale Parallelisierung von Entwicklungs- und Testprozess.

Der größte Schwachpunkt von Requirements ist deren Vollständigkeit. Es gibt kein messbares Kriterium für die Vollständigkeit von Requirements. Die Architektur hat Ihre Schwachstelle im Detailgrad. Welcher Detailgrad der Architektur der Richtige ist, muss in jedem Projekt neu bewertet werden. Eine allgemeingültige Aussage ist kaum möglich.

Ein Requirement oder Architekturaspekt, welcher nicht vorhanden ist, kann aber mit der Testart spezifikationsbasiertes Testen auch nicht getestet werden. Es entstehen Testlücken. Darüber hinaus ist es auch nicht möglich alle Aspekte aller Requirements vollständig durch Tests nachweisen. Ebenso gibt es auch kein eindeutiges Kriterium, um festzustellen, wann ein Requirement vollständig ist. Auch dadurch ergeben sich ganz automatisch Testlücken.

Strukturbasierte Testentwurfsverfahren

Strukturbasierte Testverfahren sind auch als White-Box Testverfahren bekannt. Im Mittelpunkt des Tests steht der Nachweis der Source Code Struktur. In der Praxis sind folgende 3 Kategorien von Strukturtests anzutreffen:

• Anweisungsüberdeckung (Statement Coverage)
• Zweigüberdeckung (Branch Coverage)
• MC/DC (Modified Condition / Decision Coverage)

Die Stärke dieses Testentwurfsverfahren liegt darin, dass die Vollständigkeit für die 3 Kategorien eindeutig bestimmbar ist. In diesem Sinne ist das strukturbasierte Testentwurfsverfahren komplementär zum spezifikationsbasierten Verfahren.

Die wesentlichen Nachteile des Verfahrens liegen in folgenden Bereichen:

• Die kritischen Fehler in einer Software finden sich meist in der Funktionalität und nicht in der Struktur des Codes. Das reine strukturbasierte Testen, kann aber kaum funktionale Fehler finden
• Um die strukturelle Überdeckung des Source Codes nachzuweisen muss für den Test der Source Code verändert werden. Diese Veränderung des Codes wirkt sich negativ auf die Performanz des Systems aus. Dies wiederum hat in den allermeisten Fällen zur Folge, dass die strukturelle Überdeckung nur auf Unitebene nachgewiesen werden kann.
• Auch die strukturbasierten Tests, weisen bei der Anwendung der genannten Überdeckungsmaße nur einen Bruchteil aller möglichen Softwarepfade ab. Ein vollständiger Test aller möglichen Softwarepfade ist nicht möglich.

Die non-intrusive Systembeobachtung wird zukünftig die Möglichkeit bieten, die strukturelle Source Code Überdeckung ohne Beeinflussung der Performanz des Systems zu messen. Damit eröffnen sich neue Möglichkeiten für den Einsatz dieses Testverfahrens. Mehr Informationen dazu finden Sie in folgenden Blogbeiträgen:

• Die non-intrusive Messung der strukturellen Coverage
• Vollständige Requirements mit Daten- und Kontrollflussanalyse

Effizienzbasierte Testentwurfsverfahren

Die prominentesten Vertreter sind die Stress- und Lasttest. Die effizienzbasierte Testentwurfsverfahren, stellen eine wichtige Untermenge der spezifikationsbasierten Tests dar. Die Vor- und Nachteile sind entsprechend ähnlich.

Die effizienzbasierten Testverfahren, stellen allerdings eine besondere Herausforderung für die Testumgebung dar. Zum Nachweis von Antwortzeiten eines Systems von z.B. 10ms, muss das Testsystem in der Lage sein in einem Zeitraster < 10ms zu arbeiten. Ein anderes Beispiel ist der Nachweis von maximalen Strömen welche gleichzeitig über bestimmte Schnittstellen fließen können. Die Elektronik des Testsystems muss für diese maximale Wert ausgelegt sein.

Wie man anhand dieser Beispiele erahnt, sind die effizienzbasierten Testentwurfsverfahren starke Kostentreiber für die Testumgebung.

Eine weitere Besonderheit dieser Testverfahren ist, dass viele Tests nur aussagekräftig sind, wenn gleichzeitig zum Test auch eine fundierte Analyse erstellt wird. In den Meisten Fällen ist anhand des Tests nicht nachvollziehbar, dass der wirklich schlechteste mögliche Fall des Systems getestet wurde. Genau diese Begründung muss die beigefügte Analyse liefern.

Erfahrungsbasierte Testentwurfsverfahren

Das bekannteste erfahrungsbasierte Testentwurfsverfahren ist sicherlich das explorative Testen. Aus meiner Sicht zählt auch das Useability Testen zu den erfahrungsbasierten Testentwurfsverfahren. Der Vorteil liegt in der Möglichkeit der Kreativität beim Testen möglichst viel Spielraum zu geben. Der Tester soll seine ganze Systemerfahrung einbringen und kreative Testszenarien erstellen. Erfahrungsbasierte Tests stellen meist eine optimale Ergänzung zu spezifikationsbasierten Tests dar. Es werden viele Testszenarien erstellt, welche häufig Lücken bei den Requirements aufdecken helfen.

Der Nachteil liegt darin, dass die Qualität der Tests direkt korreliert mit der Erfahrung und der Qualität des Testers. Häufig stellt sich bei erfahrungsbasierten Tests auch die Herausforderung, dass gar nicht eindeutig und schnell entschieden werden kann ob ein Testergebnis korrekt oder fehlerhaft ist. Häufig ist es auch schwierig, einen eindeutig reproduzierbaren Testablauf zu erstellen. Der Umgang mit Tests welche einen Fehler gefunden haben, aber nicht reproduzierbar sind, stellen eine der größten Herausforderungen im Test Engineering überhaupt dar.

Risikobasierte Testentwurfsverfahren

Der Vorteil der risikobasierten Testentwurfsverfahren liegt darin, dass der Fokus auf dem Finden von Fehlern in den Softwareteilen mit dem größten Risiko liegt. Aus diesem Blickwinkel handelt es sich also um ein sehr effizientes Testverfahren.

Andererseits ist die Methodik zur Identifikation der Tests, welche das betrachtete Risiko optimal abdecken nicht ausgereift. In der Praxis hängt die Qualität der Ergebnisse stark vom individuellen Tester ab. In diesem Sinne ähneln sich damit die erfahrungsbasierten und die risikobasierten Testentwurfsverfahren.

Neue Ansätze für das risikobasierte Testen gehen dahin, dass Daten über die Änderungshäufigkeit, Fehler und Testabdeckung von Software Funktionen gesammelt werden. Anhand dieser Daten werden die Tests für Regressionstests priorisiert. Aus dem Software Engineering ist bekannt, das alle 3 genannten Aspekte die Wahrscheinlichkeit für neue Fehler in der Software deutlich erhöhen. Es ist also nur folgerichtig den Testaufwand auf Softwareteile welche sehr fehleranfällig sind, häufig geändert werden oder noch nie getestet wurden zu fokusieren.

Dieser Ansatz kommt vorallem für umfangreiche Softwareprodukte mit einer hohen Zahl an vorhandenen Tests zur Anwendung. Insbesondere dann, wenn die Durchführung aller Tests mehrere Tage dauert.

Fazit

Einen vollständigen Test von Software gibt es nicht. Daher wurden im Test Engineering verschiedene Testentwurfsverfahren entwickelt, welche jeweils unterschiedliche Schwerpunkte festlegen bei der Auswahl von Testfällen. Langjährige Erfahrung hat gezeigt, dass die spezifikationsbasierten und und als Untermenge davon die effizienzbasierten Testentwurfsverfahren die Wichtigsten sind wenn ein vollständiger Test des Produktes erreicht werden soll. Dass Verfahren ist darauf ausgelegt, schon zu Beginn des Projektes alle Testaspekte systematisch zu berücksichtigen.

Spezifikationsbasierten Testverfahren haben den Nachteil, dass eine Vollständigkeit nicht erreicht werden kann. Daher ist es häufig sinnvoll, strukturbasierte oder erfahrungsbasierte Testentwurfsverfahren ergänzend einzusetzen.

Damit werden dann wichtige Software Releases vollständig getestet. Die Testausführungszeit spielt für solche Situationen eine untergeordnete Rolle.

Risikobasierte Testentwurfsverfahren sind dann zu empfehlen, wenn ein schnelles Feedback über Änderungen einer Software notwendig sind und die Ausführung aller Tests länger als eine Nacht dauern würde. Ein weiteres Anwendungsszenario dafür sind nicht sicherheitsrelevante Softwareprojekte bei denen erfolgskritische Aspekte nicht effizient mit Requirements definierbar sind (z.B. Software mit komplexen HMIs). In diesen Projekten kommen dann die Vorteile der risikobasierten Testentwurfsverfahren besonders zur Geltung.

Weitere HEICON Blog Beiträge zum Thema

• Requirement- und Test Traceability – Mit Köpfchen!
• Wieviel Requirement Ebenen braucht man in der FuSi
• Guter Safety Software Entwicklungsprozess – Was ist das?
• Managementaspekte in der Validation und Verifikation
• Strukturelle Source Code Überdeckung – Aufwand ohne Nutzen?

Ihre individuellen Fragen zum Test Engineering beantworten wir gerne in einem ersten, kostenlosen 30min Beratungsgespräch!
Vereinbaren Sie gleich einen Termin: Eine kurze Mail an info[at]heicon-ulm.de genügt, oder greifen Sie gleich zum Telefonhörer: +49 (0) 7353 981 781 (Mo bis Fr 08:00 – 18:00Uhr).