• Twitter
  • LinkedIn
  • Xing
+49 7353 981781
Heicon Ulm
  • HOME
  • UNTERNEHMEN
  • PRODUKTE
  • HEICON BLOG
  • Deutsch
    • Deutsch
    • English
  • Menü Menü
Du bist hier: Startseite1 / B_Validation und Verifikation2 / Implizites Testen – Eine gute Idee (Teil 1)?

Implizites Testen – Eine gute Idee (Teil 1)?

B_Validation und Verifikation

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

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).

19. Februar 2017/1 Kommentar/von HEICON Global Engineering GmbH
Schlagworte: Entwicklungsprozesse, Funktionale Requirements, Kategorien von Requirements, Software Engineering, Software Requirements, Software Testing, Verifikation
Eintrag teilen
  • Teilen auf Facebook
  • Teilen auf Twitter
  • Teilen auf WhatsApp
  • Teilen auf LinkedIn
https://heicon-ulm.de/wp-content/uploads/2020/06/DI1A5942_klein_VV_deutsch.jpg 431 553 HEICON Global Engineering GmbH https://heicon-ulm.de/wp-content/uploads/2020/07/heicon-logo-5.png HEICON Global Engineering GmbH2017-02-19 11:14:362021-06-06 19:59:06Implizites Testen – Eine gute Idee (Teil 1)?
Das könnte Dich auch interessieren
Industrie Spezifikation Architektur Requirement in IEC 61508; Gibt’s da Unterschiede?
Requirement Engineering User Stories – Die besseren Requirements?
Validation und Verifikation Implizites Testen – Eine gute Idee (Teil 2)?
ISO26262 ISO 26262 kalibrierbare Software
Bahn EN50128 konfigurierbare Systeme: Fluch oder Segen?
Requirement Engineering Die Herausforderung Nicht-Funktionale Requirements!
1 Kommentar

Trackbacks & Pingbacks

  1. Implizites Testen – Eine gute Idee (Teil 2)? | HEICON sagt:
    27. März 2017 um 16:20 Uhr

    […] ersten Teil des Blogs habe ich den Begriff „Implizites Testen“ definiert und Ursachen dafür diskutiert. Im zweiten […]

    Antworten

Hinterlasse einen Kommentar

An der Diskussion beteiligen?
Hinterlasse uns deinen Kommentar!

Schreibe einen Kommentar Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Kategorien

  • A_Requirement Engineering
  • B_Validation und Verifikation
  • C_Konfig-/ Änderungsmanagement
  • D_Security
  • FuSi_Allgemein
  • FuSi_Automotive
  • FuSi_Bahn
  • FuSi_Industrie
  • FuSi_Landwirtschaft
  • FuSi_Luftfahrt

Kontakt

HEICON Global Engineering GmbH
Dipl. Ing. (FH) Martin Heininger
Kreuzweg 22
88477 Schwendi

Tel.: +49 7353 – 98 17 81
Mobil: +49 176 – 24 73 99 60

Email: info[at]heicon-ulm.de

IMPRESSUM  |  DATENSCHUTZ

User Stories – Die besseren Requirements?Requirement EngineeringValidation und VerifikationImplizites Testen – Eine gute Idee (Teil 2)?
Nach oben scrollen