• 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 2)?

Implizites Testen – Eine gute Idee (Teil 2)?

B_Validation und Verifikation

Im ersten Teil des Blogs habe ich den Begriff „Implizites Testen“ definiert und Ursachen dafür diskutiert.
Im zweiten Teil geht es nun um die Nachteile solcher Tests und um Lösungsansätze um möglichst diese Nachteile gar nicht erst entstehen zu lassen.

Nachteile von implizitem bzw. indirektem Testen?

Wenn man Projekte im Nachhinein analysiert, dann stellt man fest, dass es einen Zusammenhang gibt, zwischen impliziten Tests und der Anzahl NICHT gefundener Fehler. Durch implizites Testen verliert man eine wesentliche Stärke des Requirements basierten Testens, nämlich dass man die Funktionalitäten eines Systems in kleinen Häppchen in Requirements definiert und diese dann alle vollständig in Tests nachweist. Implizites Testen macht das gerade nicht mehr. Es werden oft ganze Requirements gar nicht mehr explizit nachgewiesen. Das kann man auch an dem Beispiel Requirement aus dem ersten Teil des Blogs gut sehen:
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.

Ob die interne Software Variable wirklich so stehen wie im Req. beschireben ist, wenn die Bedingungen aus Req. A erfüllt sind wird nicht gezeigt. Ebenso wird nicht explizit durch einen Test bewiesen, dass die Variablen entsprechend gesetzt sein müssen um die Reaktion gemäß Req. B auszulösen.
Bei steigender Systemkomplexität steigt nun die Gefahr, dass man Fehler im System durch den Test nicht mehr findet.
Neben einer nicht adäquaten Testumgebung kann die Ursache für implizites Testen auch der Versuch sein die Architektur eines Systems per Tests nachzuweisen. Statt die Architektur grafisch zu definieren, werden oft textuelle Requirements erstellt, die dann eben nur implizit testbar sind. Aus Kosten/Nutzen Gesichtspunkten kann man klar sagen, dass diese Art von textuellen Requirements überwiegend nutzlos sind. Ohne diese Art von Requirements hätte man die gleiche Produktqualität erreicht, aber zu günstigeren Kosten.
Technisch gesehen, hat man den Vorteil, wenn solche Requirements nicht vorhanden sind, dass die Dokumentation deutlich verständlicher, übersichtlicher und transparenter wird.
Generell leiden viele Projekte heutzutage eher unter zu vielen, als unter zu wenigen Requirements. Architekturbeschreibungen in Form von Requirements, sowie die Definition von Requirements auf der falschen Ebene sind die wesentlichen Ursachen dafür.

Lösungsansätze:

Nachfolgend einer grober Überblick über erfolgsversprechende Lösungsansätze um implizites Testen zu minimieren und dadurch die Effizienz und den Kosten/Nutzenfaktor im Projekt deutlich zu steigern:

  • Bewusste Strategie für die Erstellung von Requirements von Anbeginn des Projektes
    • Umgang mit unterschiedlichen Kategorien von Requirements
    • Definition der Requirements auf der angemessenen Ebene
    • Für 90% oder mehr aller Embedded Systeme Definition von höchstens 2 Ebenen von Requirements
    • Individuelle Festlegung der Testebene bzw. Testumgebung für jedes Requirement
  • Definition einer effizienten Teststrategie von Anbeginn des Projektes
    • Definition und bewusste Anwendung einer Systemtestumgebung
    • Definition und bewusste Anwendung einer HW/SW Integrationstestumgebung
    • Bei Projekten mit hohem Softwareumfang oder bei sicherheits-relevanten Projekten Definition und bewusste Anwendung einer SW/SW Integrationstestumgebung

Weitere HEICON Blog Beiträge zum Thema

  • Implizites Testen – Eine gute Idee (Teil 1)?
  • 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).

27. März 2017/0 Kommentare/von HEICON Global Engineering GmbH
Schlagworte: Funktionale Requirements, Implizites Testen, Kategorien von Requirements, Software Engineering, Software Requirements, Software Testing, Validation, 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-03-27 16:20:102021-06-06 19:55:46Implizites Testen – Eine gute Idee (Teil 2)?
Das könnte Dich auch interessieren
Funktionale Sicherheit Compiler für sicherheitsrelevante Software – Was ist zu tun?
Validation und Verifikation Strukturelle Source Code Coverage und Requirements – Gibt’s da einen Zusammenhang?
Validation und Verifikation Implizites Testen – Eine gute Idee (Teil 1)?
Konfigurationsmanagement: Eine anspruchsvolle Aufgabe!
Requirement Engineering Requirement Engineering für Embedded- und IT-Systeme – Es wird Zeit das sich die Embedded Community der Unterschiede bewusst wird!
ISO26262 Fault Injection Test in ISO 26262 – Braucht man den wirklich?
0 Kommentare

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

Implizites Testen – Eine gute Idee (Teil 1)?Validation und VerifikationFunktionale SicherheitGuter Safety Software Entwicklungsprozess – Was ist das?
Nach oben scrollen