Technische Universität München

Zentralübung Automotive Software Engineering –

Übungsblatt 8

Sascha Schwind

Technische Universität München

Produktorientierte QS

Statisch Überprüfung von Coding Standards, z.B. MISRA-C Metriken: Bewertung der Code-Komplexität, z.B. Cyclomatic

Complexity, McCabe Zusicherung, z.B. Hoare Kalkül Theorem Prüfer, z.B. Isabelle Model Checking, z.B. SMV Reviews/Inspektion

Dynamisch Tests Simulation

Welche QS-Maßnahmen sind

konstruktiv, welche sind analytisch?

Technische Universität München

Prozessorientierte QS

Vorgaben Definierter Entwicklungsprozess, z.B. Instanziierung eines

Standardvorgehensmodells, wie V-Modell XT Normen und Standards, Anforderungen an den Prozess, z.B.

CMMI Bewertung

Audits Assessments, z.B. nach SPICE Welche QS-

Maßnahmen sind konstruktiv, welche sind analytisch?

Technische Universität München

Modellbasiertes Testen

Testvariationen: Modell als Testorakel Umgebungsmodell Runtime Verification

„Testebenen“: HIL, SIL

Meist Generierung von Testfällen: Input- und Outputsequenzen

Technische Universität München

Fall 1: Testmodell = Implementierungsmodell

Was wird dabei getestet? Code-Generator Glue Code Hardware/Treiber/Basissoftware/OS Ggf. Diskretisierungsfehler

Requirements

Modell

Code Abstrakte Testfälle

Plattform Konkrete Testfälle

Test TreiberDeployment/Glue Code

TestfallgenerierungCodegenerierung

Unterschiede?

Technische Universität München

Fall 2: Eigenes Testmodell

Was wird dabei getestet? Applikationslogik Interpretation der Anforderungen, Vollständigkeit der Anforderungen (z.T.

Validierung)Aber: Aufwändig, weil redundante Entwicklung! Deshalb ist Abstraktion im Testmodell

notwendig!

Requirements

Impl. Modell

Code Abstrakte Testfälle

Plattform Konkrete Testfälle

Test TreiberDeployment/Glue Code

TestfallgenerierungCodegenerierung

Testmodell

Unterschiede?

Technische Universität München

Statische Analyse [Righting Software, Larus et. al.]

Kann man alle Fehler durch statische Analyse finden? Nein, Halteproblem: Nicht-triviale Eigenschaften sind nicht entscheidbar.

Statische Analysewerkzeuge sind immer ein Kompromiss zwischen Präzision und Vollständigkeit: Vollständig aber unpräzise: Heuristik-basierte Tools, z.B. Lint,

FindBugs, FxCop, … ( False Positives) Unvollständig aber präzise: Abstrakte Simulation, Überprüfung von

Vor- /Nachbedingungen und Invarianten, Prüfung gegen formale Spezifikation (z.B. in Temporaler Logik), …

® Immer: Fokus auf bestimmte Eigenschaften/Abstraktion!® Probleme der Plattform werden oftmals ignoriert.

Technische Universität München

Generierung von Testfällen

Kann man ein System vollständig testen? Man kann meist nicht alle Testfälle überprüfen, da exponentiell

viele (Kreuzprodukt aller Inputtypen)! Meist wird deshalb versucht bestimmte Überdeckungsmaße

(Metriken für Testqualität) zu erreichen: Anforderungsüberdeckung Ein-/Ausgabeüberdeckung (Äquivalenzklassenbildung) Anweisungsüberdeckung Zweigüberdeckung Pfadüberdeckung Randfälle (Analog für Automaten: Knoten-/Kanten-/Pfadüberdeckung)