Zentralübung Automotive Software Engineering – Übungsblatt 8

Präsentation zum Thema: "Zentralübung Automotive Software Engineering – Übungsblatt 8"—  Präsentation transkript:

1 Zentralübung Automotive Software Engineering – Übungsblatt 8
Sascha Schwind

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

3 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?

4 Modellbasiertes Testen
Testvariationen: Modell als Testorakel Umgebungsmodell Runtime Verification „Testebenen“: HIL, SIL Meist Generierung von Testfällen: Input- und Outputsequenzen

5 Fall 1: Testmodell = Implementierungsmodell
Requirements Modell Codegenerierung Testfallgenerierung Code Abstrakte Testfälle Deployment/Glue Code Test Treiber Plattform Konkrete Testfälle Unterschiede? Was wird dabei getestet? Code-Generator Glue Code Hardware/Treiber/Basissoftware/OS Ggf. Diskretisierungsfehler

6 Fall 2: Eigenes Testmodell
Requirements Impl. Modell Testmodell Codegenerierung Testfallgenerierung Code Abstrakte Testfälle Deployment/Glue Code Test Treiber Plattform Konkrete Testfälle Unterschiede? 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!

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

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