In größeren sicherheitskritischen Projekten begegnet mir immer wieder mal der Ausspruch: „Naja, das Requirement A wird mit dem Test XY indirekt oder implizit nachgewiesen!“. Ist Ihnen das auch schon mal passiert? Haben Sie auch schon mal erlebt, was in späten Projektphasen passieren kann, wenn man viele Requirements indirekt getestet hat?
Der Blog definiert im Teil 1 den Begriff und er beleuchtet die Ursachen von Impliziten Testen.

Was versteht man unter indirektem oder implizitem Testen?

Implizites oder indirektes Testen von Requirements bedeutet, dass es keine unmittelbare Möglichkeit gibt, die Forderung des Requirements mit dem vorhandenen Testequipment nachzuweisen. Stattdessen werden andere direkt nachweise Requirements gesucht. Dann werden Argumente entwickelt, warum mit dem Test dieser Requirements auch die indirekten Requirements nachgewiesen sind.

Machen wir ein Beispiel:
Req. A: Wenn Weight on Wheels = TRUE am Discreten Input DS 1 anliegt dann sollen die Software Flags SWW1 = TRUE und SWW2 = FALSE gesetzt werden.

Req B: Wenn SWW1 = TRUE und SWW2 = FALSE sind dann soll die AFDX Msg „ON_GROUND gesendet werden.

Der Zugriff auf interne Software Variablen ist in vielen Testumgebungen in der Regel nicht möglich. Damit ist es im Test nicht möglich, den Status der Software Variable direkt zu prüfen. Es ist nur ein indirekter Test möglich in dem man den Diskreten Input DS1 auf TRUE setzt und dann prüft ob die AFDX Msg. „ON_GROUND“ gesendet wird. Dies ist ein typisches Beispiel von indirekten Tests.

Typische Ursachen:

Grundsätzlich sehe ich zwei Ursachen für die Entstehung vieler indirekter Tests:

• Tests sollen die Architektur nachweisen
• Testumgebung ist für die zu testenden Requirements nicht adäquat (Beispiel oben)

Über den ersten Fall habe ich auch schon in anderen Blogs geschrieben (IEC61508 Spezifikation_Architektur_Requirements_Gibts_da_Unterschiede). Der Nachweis der Korrektheit der Architektur ist mittels Test nicht möglich. Wenn man eine Architektur über eine Test nachweist, dann wird das immer indirekt passieren, d.h. man testet die Funktionalität die durch die Architektur implementiert wird. Man testet aber nicht direkt die Architektur.

Der zweite Fall entsteht häufig, wenn zu Beginn des Projektes nicht klar definiert wird, in wie vielen Schritten der Systemaufbruch vollzogen wird. Industrieweit man häufigsten sind zwei Ebenen für ein klassisches Steuergerät, bestehend aus einer Hardware mit einem Mikroprozessor und der Software für den Mikroprozessor. In den besonders sicherheitskritischen Projekten der Luftfahrt werden dafür drei Ebenen (System, High-Level (SW), Low-Level(SW)) gefordert.
Die Notwendigkeit des indirekten Testens entsteht, wenn zwar Requirements für die zweite oder dritte Ebene beschrieben sind, aber nur eine Testumgebung für die Systemebene vorhanden ist.
Die Nachteile die sich aus dem indirekten Testen ergeben, so Ansätze zur Minimierung solcher Tests werden im zweiten Teil des Blogs diskutiert.

Weitere HEICON Blog Beiträge zum Thema

• Implizites Testen – Eine gute Idee (Teil 2)?
• Testen von Plattformen: Eine spannende Herausforderung!
• Managementaspekte des Testens
• Psychologie des Testers

Sind Sie bereit für einen Status Workshop um das Verbesserungspotential in Ihrem Test Engineering zu identifizieren? Dann senden Sie eine Mail an info[at]heicon-ulm.de oder vereinbaren Sie einen Telefontermin unter +49 (0) 7353 981 781.