Software in sicherheitsrelevanten Systemen

Software in sicherheitsrelevanten Systemen

Ralf Pinger / Stefan Gerken

Sommersemester 2014

Software in sicherheitsrelevanten SystemenSommersemester 2014

Model basedDevelopment

Model basedTesting

Modeltrans-formation

Applicationmodel Test model

Code (executable)


Testcases (executable)

Analysis

Model based Software Engineering

24.04.23 Ralf Pinger / Stefan GerkenPage 2

Kapitel 6 - Software für sicherheitsrelevante Systeme

Inhaltsübersicht

1. CENELEC2. EN 50128 – eine Gebrauchsanleitung3. Anforderungen4. SW-Entwicklungsmethoden 5. SW-Test 6. Qualität 7. Qualitätssicherung von Entwicklungswerkzeugen



Model basedTesting



Code (executable)



Analysis



6.1 CENELEC

CENELEC ist das Europäische Normungskomitee für Elektrotechnik (Comité Européen de Normalisation Électrotechnique).

In der CENELEC sind die nationalen Normungskomitees von vielen europäischen Staaten vertreten (z.B. DKE - Deutsche Kommission Elektrotechnik, Elektronik, Informationstechnik im DIN und VDE).

In diesen Staaten werden nationale Normen durch CENELEC-Normen sukzessive ersetzt.

Die CENELEC hat unter anderem Normen zur funktionalen Sicherheit im Bahnbereich veröffentlicht



Model basedTesting



Code (executable)



Analysis



6.1 CENELEC – Struktur der Bahnnormen



Model basedTesting



Code (executable)



Analysis



6.1 CENELEC – Lebenszyklus nach EN 50126

Concept

System Definition andApplication Conditions

Risk Analysis

System Requirements

Apportionment ofSystem Requirements

Design andImplimentation

Manufacture

Installation

System Validation(Including Safety Acceptance

and Commissioning)

System Acceptance

Operation andMaintenance

PerformanceMonitoring

Modificationand Retrofit

De-commissioningand Disposal

Re-apply Lifecycle(See Note 1)

14

131112

10

9

8

7

6

5

4

3

2

1

( See Note 2)Re-apply Risk Analysis

Für jede Phase werden definiert

• Ziele• Input (Dokumente)• Anforderungen• Output (Dokumente)• Verifikationsaufgaben

Der Lebenszyklus umfaßt wesentlich mehr als nur die Entwicklung und beinhaltet Aufgaben für Hersteller und Betreiber!

Bild: EN 50126



Model basedTesting



Code (executable)



Analysis



6.1 CENELEC- Obligatorische Anforderungen

Klar definierte Verantwortlichkeit für RAMS-Aufgaben

Kompetenznachweise

Ausarbeitung und Durchführung eines RAM Programms

Ausarbeitung und Durchführung eines Sicherheitsplans

Implementierung eines EN 50126 und ISO 900x konformen Geschäftsprozesses

Effektives Konfigurationsmanagement für RAMS-Aufgaben

CENELEC EN 50126 ist seit 1.4.2000 in allen CENELEC-Mitgliedsländern als nationale Norm in Kraft gesetzt.



Model basedTesting



Code (executable)



Analysis



6.2 EN 50128 – eine Gebrauchsanleitung

Normen sind keine Gesetze und haben nur Empfehlungscharakter

Haben einen definierten Sprachgebrauch (hier DIN)

positiv negativ

Anforderung(requirement) muss shall darf nicht shall not

Empfehlung(recommendation)

sollte should sollte nicht should not

Zulässigkeit(permission)

darf may braucht nicht need not

Möglichkeit(possibility)

kann can kann nicht cannot



Model basedTesting



Code (executable)



Analysis



6.2 EN 50128 – Anwendungsbereich

Verfahren und technische Anforderungen für die Entwicklung von programmierbaren elektronischen Systemen

gesamter Bereich der Sicherheitsanwendungen

gilt für jegliche sicherheitsrelevante Software, die in Eisenbahnsteuerungs- und -überwachungssystemen verwendet wird, einschließlich:

Anwendungsprogrammierung; Betriebssysteme; unterstützende Werkzeuge; Firmware.

Anwendungsprogrammierung schließt Programmierung in Hochsprache, Maschinensprache und speziellen Anwendungssprachen ein (z. B.: ladder logic bei speicherprogrammierbaren Steuerungen).

gilt auch für Änderungen und Erweiterungen an bestehender Software



Model basedTesting



Code (executable)



Analysis



6.2 EN 50128 – Aufbau der Norm

Normativer Textteil Normative Anhänge A, B Informativer Anhang C, D

Normativer Text

Anhang DAnhang B

Auswahl von

Methoden und

Techniken

Informationen zuMethoden / Techniken

Kapitel

Referenzen (D.nn)

Anhang A

Anhang CSchlüsselrollen und Verantwortlichkeiten

Zusammenfassung der Dokumentenkontrolle



Model basedTesting



Code (executable)



Analysis



6.2 EN 50128 – Beispiel 1: Normativer Textteil

7.2 Software-Anforderungen7.2.1 Ziele7.2.1.1 Beschreibung eines vollständigen Satzes von Anforderungen an die Software, der alle System- und Sicherheitsanforderungen erfüllt, und einen umfassenden Satz von Dokumenten für jede spätere Phase bereitstellt.7.2.1.2 Beschreibung der Gesamtsoftware-Testspezifikation.7.2.2 Eingangsdokumente1)System-Anforderungsspezifikation …7.2.3 Ausgangsdokumente1)Software-Anforderungsspezifikation...

7.2.4 Anforderungen7.2.4.1 Eine Software-Anforderungsspezifikation muss unter der Verantwortung des Anforderungsmanagers auf der Grundlage der Eingangsdokumente nach 7.2.2 erstellt werden. Die Anforderungen in 7.2.4.2 bis 7.2.4.15 beziehen sich auf die Software-Anforderungsspezifikation.7.2.4.2 Die Software-Anforderungsspezifikation muss die geforderten Eigenschaften der zu entwickelnden Software darstellen. Diese Eigenschaften, die alle in der Normenreihe ISO/IEC 9126 (mit Ausnahme der Sicherheit) definiert sind, müssen einschließen:…7.2.4.3 Der Software-Sicherheits-Integritätslevel muss nach der Definition in Abschnitt 4 abgeleitet und in der Software-Anforderungsspezifikation festgehalten werden.



Model basedTesting



Code (executable)



Analysis



6.2 EN 50128 – SIL

SILheißt Sicherheitsanforderungsstufe 5 SIL-Stufen

0 = nichtsichere Anwendungen 1 = niedrigste Anforderungsstufe 4 = höchste Anforderungsstufe

2 Klassen für sichere Anwendungen (1,2) und (3,4)

Maßnahmen sind notwendig bei unter-schiedlichen SSAS innerhalb eines Systems



Model basedTesting



Code (executable)



Analysis



6.2 EN 50128 – Beispiel 1 aus Anhang A



Model basedTesting



Code (executable)



Analysis



6.2 EN 50128 – Beispiel 1 aus Anhang D

D.13 Entscheidungstabellen (Wahrheitstabellen) (en: Decision Tables (Truth Tables))

Ziel

Erstellen einer klaren und zusammenhängenden Spezifikation und Analyse komplexer logischer Kombinationen und Beziehungen.

Beschreibung

Diese verwandten Verfahren benutzen zweidimensionale Tabellen zur Kurzdarstellung logischer Beziehungen zwischen boolschen Programmvariablen.

Durch die Kürze und die tabellarische Form eignen sich beide Verfahren zur Analyse komplexer logischer Kombinationen, ausgedrückt in codierter Form.

Beide Verfahren können ausführt werden, falls sie als Spezifikation benutzt werden.



Model basedTesting



Code (executable)



Analysis



6.2 EN 50128 – Beispiel 2 aus Anhang A

Quelle: EN 50128



Model basedTesting



Code (executable)



Analysis



6.2 EN 50128 – Beispiel 2 aus Anhang A (Fortsetzung)

Quelle: EN 50128



Model basedTesting



Code (executable)



Analysis



6.2 EN 50128 – Beispiel 2 aus Anhang D

Quelle: EN 50128



Model basedTesting



Code (executable)



Analysis



6.2 EN 50128 – Beispiel 2 aus Anhang D (Fortsetzung)

Fortsetzung D.54

Quelle: EN 50128



Model basedTesting



Code (executable)



Analysis



6.2 EN 50128

Quelle: EN 50128



Model basedTesting



Code (executable)



Analysis



6.2 EN 50128 – Prozess

Ergebnisse

Phase

VerVal

Quelle: EN 50128



Model basedTesting



Code (executable)



Analysis



6.2 EN 50128 – Verifikation und Validierung

Verifikation: Untersuchungsprozess mit anschließender, auf Nachweisen beruhender Beurteilung, dass die Ergebnisse (Prozess, Dokumentation, Software oder Anwendung) einer bestimmten Entwicklungsphase die Anforderungen dieser Phase hinsichtlich Vollständigkeit, Richtigkeit und Konsistenz erfüllt

DIN EN 50128, März 2012

Validierung: Analyseprozess gefolgt von einer auf Nachweisen beruhenden Beurteilung, ob ein Objekt (z. B. Prozess, Dokumentation, Software oder Anwendung) den Bedarf des Nutzers erfüllt, insbesondere bezüglich Sicherheit und Qualität, sowie mit einem Schwerpunkt auf die betriebliche Eignung für den Verwendungszweck in der vorgesehenen Betriebsumgebung

DIN EN 50128, März 2012

Wird richtig entwickelt

Ist das Richtige entwickelt worden?



Model basedTesting



Code (executable)



Analysis



6.2 EN 50128 – Dokumente / Ergebnisse

Definitionen / Anforderungen zu den Phasen des Lebenszyklus‘ (Textteil)

Vorgaben von Maßnahmen und Tools (Anhang A)

Vorgaben zu Kompetenzprofilen (Anhang B)

Vorgaben zu Reviews (Verifikation)

Verfolgbarkeit der Anforderungen



Model basedTesting



Code (executable)



Analysis



6.2 EN 50128 – Rollen und Unabhängigkeiten

Anerkannter Fachbetrieb:Der Gutachter kann auch der entwickelnden Firma unterstellt sein, wenn eine ausreichende Unabhängigkeit zur entwickelnden Abteilung gewährleistet ist

Voraussetzung:Anerkennung durch Zulassungsbehörde wie z.B. EBA

Quelle: EN 50128



Model basedTesting



Code (executable)



Analysis



6.2 EN 50128 – Aufgaben und Rollen

Quelle: EN 50128



Model basedTesting



Code (executable)



Analysis



6.2 EN 50128 – Zusammenfassung

Vorgaben für den Entwicklungsprozess

Festlegung von Maßnahmen und Tools

Anforderungen an Dokumente

Unabhängige Stellen



Model basedTesting



Code (executable)



Analysis



6.3 Anforderungen – Inhaltsübersicht

Inhaltsübersicht

1. Anforderungsmanagement2. Ermittlung von Anforderungen3. Rapid Prototyping4. Verfolgung von Anforderungen5. Identifikation von Anforderungen6. Umsetzung von Anforderungen7. Nachweis von Anforderungen



Model basedTesting



Code (executable)



Analysis



6.3 Anforderungen – Ziele der EN 50128

Beschreibung eines vollständigen Satzes von Anforderungen an die Software, der alle System- und Sicherheitsanforderungen erfüllt, und einen umfassenden Satz von Dokumenten für jede spätere Phase bereitstellt.

In dem durch den Software-Sicherheits-Integritätslevel festgelegten Umfang muss die Software-Anforderungsspezifikation so formuliert und strukturiert werden, dass sie vollständig, klar, genau, eindeutig, verifizierbar, testbar, wartbar und umsetzbar ist und auf alle Eingangsdokumente rückverfolgbar.

Beschreibung der Gesamtsoftware-Testspezifikation.



Model basedTesting



Code (executable)



Analysis



6.3.1 Anforderungsmanagement – Motivation

fehlende oder falsche Anforderungen

haben Auswirkungen auf das gesamte Produkt werden üblicherweise erst bei Inbetriebnahme oder später erkannt gefährden die erfolgreiche Abnahme des Produkts können Auswirkungen auf die gesamte Architektur haben

Änderungen sind entsprechend kostspielig

Anforderungsmanagement

ist eine Managementaufgabe zielt auf Effizienz zielt auf Fehlerarmut ordnet das Chaos



Model basedTesting



Code (executable)



Analysis



6.3.2 Ermittlung von Anforderungen

Ziel der Anforderungsermittlung:

Erkennen der Anforderungen des Kunden

Das bedeutet:

Definition der Systemgrenzen Definition der Schnittstellen Definition der zu erbringenden Systemfunktionen Definition der Umgebungsbedingungen Definition der zu unterstützenden Kundenprozesse Definition der gesetzlichen Rahmenbedingungen Definition der wirtschaftlichen Rahmenbedingungen …



Model basedTesting



Code (executable)



Analysis




Häufige Probleme Mensch

Sprache (Domäne vs. SW-Experte) Divergierende Meinungen von Stakeholdern Motivation zur Unterstützung

Organisationen Produktstrategie Verfügbarkeit von Stakeholdern

Fachlicher Inhalt Kritikalität des Systems Systemumfang Unterschiedliche Detaillierung von Anforderungen Nicht funktionale Anforderungen Methoden

Und vieles mehr



Model basedTesting



Code (executable)



Analysis




Bewertung der Anforderungen:

Korrektheit

Vollständigkeit

Machbarkeit

Bewertung, ob Kundenanforderung

Wichtigkeit

Kosten



Model basedTesting



Code (executable)



Analysis



6.3.3 Rapid Prototyping

Rapid Prototyping

kommt eigentlich aus dem Maschinenbau

beschreibt den schnellen Musterbau

ist als Software Engineering Methode adaptiert worden

wird in Verbindung mit agilen Vorgehensweisen eingesetzt

kann auch zur Anforderungsermittlung eingesetzt werden



Model basedTesting



Code (executable)



Analysis



6.3.3 Rapid Prototyping

Vorteile

ausführbares Anforderungsmodell macht das System „erlebbar“ Ausführbares Testmodell als Diskussionsgrundlage mit dem Kunden dienen Anforderungsmodell kann als Testmodell verwendet werden

Nachteile

Anforderungsmodell orientiert sich an einer Spezifikation oder Kundengesprächen

Anforderungsmodell ist nicht architekturgetrieben Anforderungsmodell erzeugt den Eindruck doppelter Entwicklung



Model basedTesting



Code (executable)



Analysis



6.3.3 Vom Rapid Prototype zum Design-Modell

Analysemodell Betriebssimulation

Systemverständnis

Designmodell



Model basedTesting



Code (executable)



Analysis



6.3.3 Analyse-/Design-Modell

Analyse-Modell:

schneller Prototyp

keine vollständige Durchdringung der Anforderungen notwendig

Anforderungsfehler werden frühzeitig offenbart

Schnelle Anpassbarkeit an Kundenänderungen (agil)

Ausprägungen:

Wegwerfprototyp

…

Refaktorisierung bis zum Produkt

Design-Modell:

Verständlichkeit/Wartbarkeit

Einfache Lösungen entstehen in der Regel nicht im ersten Ansatz!

Hohe Durchdringung der Anforderungen notwendig

Architektur muss weitgehend bekannt sein

Ausprägungen:

(Neu-) Entwicklung

…

Refaktorisiert aus Analyse-Modell



Model basedTesting



Code (executable)



Analysis



6.3.4 Verfolgung von Anforderungen

Ziele sind Identifikation von:

Verfeinerungen Realisierungen Wechselwirkungen Nachweisen

Nebenwirkungen der Identifikation:

Änderungsauswirkungsanalyse Regressionstests Fehleranalyse Kostenabschätzung für Änderungen



Model basedTesting



Code (executable)



Analysis



6.3.5 Identifikation von Anforderungen

Anforderung bedarf

einer eindeutigen Bezeichnung (z. B. Text, Nummer, Identifikator) eines vereinbarten Zwecks, z. B.

define refine implement test safety RAM motive annotation version

um die Verfolgbarkeit und Nachvollziehbarkeit zu gewährleisten



Model basedTesting



Code (executable)



Analysis



6.3.6 Umsetzung von Anforderungen

Arten der Umsetzung

Artefakte

Modellierung Programmierung Dokumente

Verfeinerung der Anforderungen durch neue Anforderungen

Umsetzen nicht-funktionaler Anforderungen durch Prozesse



Model basedTesting



Code (executable)



Analysis



6.3.7 Nachweis von Anforderungen

Zielgruppen:

Kunde Gutachter Zulassungsbehörde

Methoden:

Analyse Sicherheitsnachweise RAM-Nachweise Qualitätsnachweise

Test Testberichte



Model basedTesting



Code (executable)



Analysis



6.4 SW-Entwicklungsmethoden – Inhaltsübersicht

Inhaltsübersicht

1. Konventionelle Entwicklungsmethoden2. Halb-formale Entwicklungsmethoden3. Formale Entwicklungsmethoden4. Modellbasiertes Software-Engineering



Model basedTesting



Code (executable)



Analysis



6.4 SW-Entwicklungsmethoden – Ziele der EN 50128

SW-Architektur & SW-Entwurf und Design

Entwickeln einer Software-Architektur Überprüfen der Anforderungen an die System-Architektur Feststellen und Bewerten, der Wechselwirkungen zwischen Hardware und

Software Auswahl eines Entwurfsverfahrens Entwurf und Implementierung von Software Software, die analysierbar, testbar, verifizierbar und wartbar ist Auswahl eines für die geforderte Software-Sicherheitsanforderungsstufe

angemessenen Satzes von Werkzeugen Durchführung der Softwareintegration



Model basedTesting



Code (executable)



Analysis



6.4.1 Konventionelle Entwicklungsmethoden – Beispiele

Konventionelle Entwicklungsmethoden

VHIDT – Vom Hirn in die Tastatur Strukturierte Verfahren (laut EN 50128)

JSD - Jackson System Development MASCOT - Modular Approach to Software Construction, Operation and Test SADT - Structured Analysis and Design Technique SDL SSADM Yourdon - Real-time Yourdon

Modulares Vorgehen Entwurfs- und Codierstandards Streng typisierte Programmiersprache Strukturierte Programmierung Objektorientierte Programmierung



Model basedTesting



Code (executable)



Analysis



6.4.2 Modellierung – Beispiele

Methoden der Modellierung aus der EN 50128

Datenmodellierung Datenflussdiagramme Kontrollflussdiagramme Endliche Zustandsmaschinen/Zustandsübergangsdiagramme Zeit-Petri-Netze Entscheidungs-/Wahrheitstabellen Formale Methoden Leistungsmodellierung Strukturdiagramme Ablaufdiagramme



Model basedTesting



Code (executable)



Analysis



6.4.3 Formale Entwicklungsmethoden – Beispiele

Formale Entwicklungsmethoden aus der EN 50128

CSP - Communicating Sequential Processes CCS - Calculus of Communicating Systems HOL - Higher Order Logic LOTOS - Language for Temporal Ordering Specification OBJ – ist eine algebraische Spezifikationssprache Temporal Logic VDM - Vienna Development Method Z B Model Checking



Model basedTesting



Code (executable)



Analysis



6.4.4 Modellbasiertes Software-Engineering – Ursprünge

Erste Ansätze in den 80er Jahren mit den CASE-Tools

Modellierungselemente waren: SA/SD

Es gab viele Erfolge mit CASE-Tools Qualitätsverbesserung Bessere Beherrschung der Komplexität Mehr Abstraktion mehr Plattformunabhängigkeit

Die CASE-Tools hatten aber auch noch einige Unzulänglichkeiten Roundtrip-Engineering nicht möglich Formale Verifikation noch nicht ausgereift Tool-Entwicklung war nicht fortschrittlich genug Modellelemente waren für viele Probleme nicht ausreichend



Model basedTesting



Code (executable)



Analysis



6.4.4 Modellbasiertes Software-Engineering – Erläuterung

Modellbasierte Entwicklung definiert:

n Hierarchieebenen

auf jeder Ebene eine (formale, domänenspezifische) abstrakte Sprache

Transformationen zwischen den Hierarchieebenen

möglichst weitgehende Automatisierung der Transformationen

Model n

Code

Model 1

Model n - 1

Transformation

Transformation

Transformation



Model basedTesting



Code (executable)



Analysis



6.4.4 Modellbasiertes Software-Engineering

29 .text 30 0027 90 .p2align 2,,3 31 .globl main 32 .type main,@function 33 main: 34 0028 55 pushl %ebp 35 0029 89E5 movl %esp, %ebp 36 002b 83EC08 subl $8, %esp 37 002e 83E4F0 andl $-16, %esp 38 0031 83EC0C subl $12, %esp 39 0034 680E0000 pushl $.LC1 39 00 40 0039 C7050000 movl $3, a 40 00000300 41 0043 E8FCFFFF call puts 41 FF 42 0048 C7042404 movl $4, (%esp)

Assembler

Programmier- sprache

Modell

Transformation

Transformation



Model basedTesting



Code (executable)



Analysis




void Step(void) {input.AktuelleZeit.timeX = GetTickCount() -

starttime;tbl_display.hour = timeinfo->tm_hour;tbl_display.min = timeinfo->tm_min;

if ((stepcount > 1000) && (output.StarteDailyTest)) {

input.DailyTestResult.vorhanden = kcg_true; input.DailyTestResult.Result = DT_ok_TBL1p_Types;

}writeSSS(&input);do{

stepcount = stepcount + 1; TBL1p_MainMixer(&input, &output); output2display();} while(!output.HabeFertig);

}Assembler


Modell

Transformation

Transformation



Model basedTesting



Code (executable)



Analysis




Assembler


Modell

Transformation

Transformation



Model basedTesting



Code (executable)



Analysis



6.4.4 Modellbasiertes Software-Engineering – Motivation

Logisch funktionale Inhalte auf hoher Abstraktionsebene

Unabhängig von konkreter Hardwareplattform

lange Produktlebenszyklen

Effizienzsteigerung in der Entwicklung

Frühzeitige Fehleroffenbarung

stärkere Verknüpfung von Implementierung und Dokumentation

Qualitätssteigerung

Einsatz von Analysewerkzeugen (z. B. Model Checker)

Nachweis von Eigenschaften

Unterstützung der Zertifizierung von Systemen



Model basedTesting



Code (executable)



Analysis



6.4.4 Modellbasiertes Software-Engineering – Abgrenzung

Eigenschaften der modellbasierten Entwicklung (1)

Verwendung von Modellen zur Softwareentwicklung um die Abstraktion zu erhöhen

Verwendung von Generatoren/Transformatoren bei der Softwareentwicklung Auch teilweise Automatisierung möglich (je nach fachlicher Anforderung

zwischen 20% und 100%) Die erste Abstraktionsebene wird vollständig manuell erzeugt Ziel ist die Steigerung der Softwarequalität bzw. -effizienz Schlagwort „Automation durch Formalisierung“ in frühen Entwicklungsphasen Definitionen MDA, MDSD, MDSE nicht einheitlich und weichen je nach

Literaturquelle voneinander ab



Model basedTesting



Code (executable)



Analysis



6.4.4 Modellbasiertes Software-Engineering – Abgrenzung

Eigenschaften der modellbasierten Entwicklung (2)

Die Modelltransformation erzeugt Modelle zur manuellen Weiterbearbeitung MDA erfordert anwendungsspezifische Frameworks MDA erfordert plattformspezifische Generatoren MDA kann - abhängig von der Vollständigkeit der Codegenerierung – auch

änderungsunfreundlich sein MDA sagt nichts über den Abstraktionsgrad der Ebenen aus Ebenen können aufeinander aufbauen. Logische Fortsetzung des Abstraktionsgedankens bei der Entwicklung –

manuelle Drahtverbindung, Maschinencode, Assembler, Programmiersprache, Modellierungssprache



Model basedTesting



Code (executable)



Analysis



6.4.4. Modellbasiertes Software-Engineering

Modellbasierte Entwicklung

Modellbasiertes Testen

Modelltrans-formation

Applikations-modell Testmodell

lauffähiger Code

Modelltrans-formation

lauffähige Testfälle

Analyse



Model basedTesting



Code (executable)



Analysis




Ausdehnung der Abstraktionsidee auf gesamten Prozess

Entwicklung:

UML entwickelt sich zur industriellen Standardsprache SCADE für sicherheitsrelevante Systeme geeignet kommerzielle Werkzeuge im industriellen Einsatz bewährt

Testen/Analyse:

UML entwickelt sich zur industriellen Standardsprache kaum geeignete, kommerzielle Werkzeuge am Markt sehr großes Potenzial vor allem in der Sicherungstechnik



Model basedTesting



Code (executable)



Analysis



6.5 SW-Test – Inhaltsübersicht

Inhaltsübersicht

1. Konventionelle Testmethoden2. (halb-)automatisierte Testmethoden3. modellbasierte Testmethoden4. analytische Methoden5. Testende-Kriterien



Model basedTesting



Code (executable)



Analysis



Herausforderung des Testens:

Der Testling besitzt einen großen internen Zustandsraum (vielleicht 21000 interne Zustände)

Testfälle sind separat zu erstellen 215 manuell erstellte Testfälle sind schon sehr viel, aber bestimmt nicht erschöpfend

nur ein kleiner Teil des Verhaltens wird getestet

6.5 Testmethoden – Motivation

Test

Applikation

Eddington numberN_edd = 136×2256

= 1.57×1079

Zum Vergleich:• Anzahl Elektronen im sichtbaren Universum



Model basedTesting



Code (executable)



Analysis



6.5.1 Konventionelle Testmethoden

Excel-basiert, Ringbuch-Ordner oder einfach die Waldabholz-Methode

Testfälle sind in einer Tabelle aufgelistet Eingabewerte, Ausführungsbeschreibung, Erwartungswert Testausführung erfolgt manuell

Einstellen der Eingabewerte/Sequenzen Ausführen des Tests Beobachtung der Reaktionen und Vergleich mit Sollwert

Dokumentation des Tests in der Liste

Probleme: Regressionstest nur sehr aufwändig möglich Bei Software-Änderungen wird nur ein sehr kleiner Teil des Tests wiederholt

Unentdeckte Seiteneffekte möglich!



Model basedTesting



Code (executable)



Analysis



6.5.2 (halb-)automatisierte Testmethoden

Ausprogrammierte Testfälle:

Testfälle werden ausprogrammiert Erwartungswerte werden ebenfalls hinterlegt und am Ende der Ausführung

verglichen Test endet mit: „OK“ oder „FAILED“

Testausführung wird regressionsfähig Nach SW-Änderung können (alle) Testfälle wiederholt werden Ungewollte Seiteneffekte können entdeckt werden

Unterstützt durch Unit-Test-Module: JUnit, etc.

Probleme: Testfälle „folgen sehr eng den Programmstrukturen“ Änderung an SW zieht oft große Änderungen an den Testfällen nach sich



Model basedTesting



Code (executable)



Analysis



6.5.3 Modellbasierte Testmethoden

Modellbasiertes Testen

ist weitgehend noch Gegenstand der Forschung hat kaum geeignete, kommerzielle Werkzeuge am Markt hat sehr großes Potenzial vor allem in der Sicherungstechnik Testen umfasst 40 % des Gesamtaufwand eines Projekts

Zwei unterschiedliche Ausprägungen Einsatz von Standard-Sprachen Einsatz domänenspezifischer Sprachen ist möglich

Sehr hohes Potenzial zur Effizienzsteigerung Generierung sehr vieler Testfälle ist möglich:

Aber: Testorakel nicht vergessen



Model basedTesting



Code (executable)



Analysis




Modellbasiertes Testen mit Standardsprachen Verwenden einer bekannten Sprache zur Testfallmodellierung

Teilsprache der UML

Use-Case-Diagramm

Aktivitäts-Diagramm

Sequenz-Diagramm

Zustands-Diagramm

Auch andere Sprachen sind denkbar, z. B. Markov-Ketten

Generieren der Testfälle aus diesen Beschreibungen

Anpassen an die Testumgebung notwendig

Werkzeuge sind bestenfalls Baukästen



Model basedTesting



Code (executable)



Analysis




Modellbasiertes Testen mit domänenspezifischen Sprachen

Entwickeln einer domänenspezifischen Sprache

Modellieren mit Meta-Modellierungswerkzeugen

EMF (Eclipse Modeling Framework)

Metaedit (kommerzielles Werkzeug)

Topcased (Open-source-Werkzeug)

In der Regel graphische Sprachen

Entwickeln eines Generators zur Testfallerzeugung

Leichter Zugang für Domänen-Experten



Model basedTesting



Code (executable)



Analysis



Ein Fahrprofil




Model basedTesting



Code (executable)



Analysis




Editor für Fahrprofile

• Meta-Sprache in Metaedit

• Editor-Generierung

• Code-Generierung in XML-Format



Model basedTesting



Code (executable)



Analysis




• Metaedit bis zur Zwischensprache

• Unterschiedliche Back-Ends für verschiedene Zielplattformen

• Identische Testfälle für

• Simulation am PC

• Integrationstestumgebung

• Zielplattform

Domänenspezifische Sprache

MERL-Generator

XML-Zwischensprache

SSS-Generator TestanlageCPP-

Generator

SCADE-Simulator

Modul-Testumgebung

Spezifische Testumgebung



Model basedTesting



Code (executable)



Analysis




Strategie Generierung aus abstrakten Beschreibungen:

- Viele Testfälle aus einer abstrakten Beschreibung

- Basis meist Aktivitätsdiagramme oder Zustandsmaschinen

- Grundprinzip: Fallunterscheidungen “ausrollen“

- Testorakel muss separat erzeugt werden

Generierung aus festgelegten Eingabesequenzen:

- In der Regel ein Testfall pro abstrakter Beschreibung

- Basis meist Sequenz-Diagramme, Use-Case-Diagramme

- Grundprinzip: Ein “Durchlauf“ durch das System

- Erzeugung vieler Testfälle durch Mischen

- Testorakel kann mit beschrieben werden



Model basedTesting



Code (executable)



Analysis




Modellbasierte Entwicklung ist auf dem Weg zum Industriestandard

Modellbasierte Entwicklungswerkzeuge sind auch für sicherheitsrelevanteSysteme einsetzbar

Modellbasiertes Testen bietet erhebliches Einsparpotenzial

Werkzeugunterstützung für domänenspezifische Sprachen

Einfache Sprache für Domänenexperten

- Leicht zu Erlernen

- Nur der Sprachumfang der auch benötigt wird

Generierung kann durch Software-Experten leicht ausgeführt werden

Anpassung an Testumgebungen, Simulation ...



Model basedTesting



Code (executable)



Analysis



6.5.4 Analytische Methoden

Analyse

Testorakel: Ist mein Testfall durchgefallen?

Formale Verifikation: Erfüllt mein System die Anforderungen?

Timing-Analyse: Werden die Zeitanforderungen erfüllt?

Testende-Kriterien: Abdeckungsmessungen

Statische Analyse: Laufzeitfehler, Speicherverbrauch

Simulation: Wie verhält sich das System im Einsatz?

Güte des Designs: Ist die Architektur verständlich?



Model basedTesting



Code (executable)



Analysis



6.5.5 Testende-Kriterien

Testende-Kriterien

Code-Abdeckung Anweisungsüberdeckung – EN 50128 Pfadüberdeckung Modified Condition/Decision Coverage (MC/DC) – DO 178C

Funktionsüberdeckung

Requirementsüberdeckung

Schnittstellenüberdeckung



Model basedTesting



Code (executable)



Analysis



6.6.1 Prozesse

Prozesse bilden die Grundlage für

Zertifizierbarkeit Können geforderte Eigenschaften nachgewiesen werden? Ist nach dem Stand der Technik entwickelt worden?

Qualität Wurde an alles gedacht? Gibt es genügend Maßnahmen zur Fehlerreduktion?

Wartbarkeit Wo muss was geändert werden?

Vorhersagbarkeit eines Projekts Wann wird was geliefert? Wie viel kostet es?

Gerichtsfeste Nachweise



Model basedTesting



Code (executable)



Analysis



6.6.2 Fehlerkultur

Offener Umgang mit Fehlern:

Fehler in Projekten sind ganz normal

Der Gesamtprozess mit den unterschiedlichen Rollen soll gemachte Fehler erkennen und beseitigen

Erkannte Fehler dürfen/müssen offen kommuniziert werden

Das Erkennen von Fehlern ist die Grundlage für die künftige Vermeidung!



Model basedTesting



Code (executable)



Analysis



6.7 Qualitätssicherung von Entwicklungswerkzeugen

EN 50128 verlangt:

CENELEC-Norm gilt auch für „unterstützende Werkzeuge“ „angemessener Satz an Werkzeugen“ soll eingesetzt werden. Automatische Testwerkzeuge und integrierte Entwicklungswerkzeuge werden

empfohlen. Werkzeuge und Hilfsmittel sollten zum frühest möglichen Termin verfügbar

sein. Software-Werkzeuge müssen für den Zweck geeignet sein.

In der Praxis:

Werkzeuge mit Validierung, Begutachtung und Zulassung! Werkzeuge ohne Nachweis der Qualifizierung Und alles was dazwischen ist



Model basedTesting



Code (executable)



Analysis




Neue Version der EN 50128 klassifiziert Werkzeuge

T1: Kein direkter oder indirekter Einfluss auf Code: Editoren, Requirements Management Tools

T2: Verifikations- und Testwerkzeuge: Fehler im Tool erzeugen keine Fehler im Produkt, aber er bleibt evtl. unentdeckt

T3: Output hat direkten oder indirekten Einfluss auf das sicherheitsrelevante System

ISO 61508 klassifiziert Werkzeuge nach:• Einfluss des Tools auf das Ergebnis (ähnliche T1, T2, T3)• Fehleraufdeckung durch nachgelagerte Prozessschritte



Model basedTesting



Code (executable)



Analysis




Einsatz von Werkzeugen bei Automatisierung manueller Tätigkeiten

Aber das Werkzeug besitzt deterministisches Fehlerverhalten der Mensch besitzt stochastisches Fehlerverhalten

Nachgelagerte Qualitätssicherung zum Fehlerfindenkeine Qualifizierung von Werkzeugen notwendig! gleicher Prozess wie bei manueller Erstellung der Ergebnisse

Einsparen von Qualitätssicherungsschritten: Qualifizierung von Werkzeugen notwendig!



Model basedTesting



Code (executable)



Analysis




Beispiel: Compiler oder Generator

Generator mittels Validierungssuite überprüfen

Vorwärts- und Rückwärtsübersetzung mit Vergleich des Ausgangsmaterials

Zwei Mal diversitäre Vorwärtsübersetzung mit Ergebnisvergleich

Applikationstest mit Abdeckungsmessung auf Ebene des Bytecodes oder Assemblers

Generierung der Testfälle aus dem Modell mit Abdeckungsmessung

Generierung der Testfälle aus einem Testmodell mit anschließender Abdeckungsmessung

Formal beweisbare Übersetzung



Model basedTesting



Code (executable)



Analysis




Validierungssuite

ausführliche Sammlung von Testfällen

Bei Unvollständigkeit der Sammlung bleiben ungetestete Situationen übrig.

Testendekriterien bleiben genauso entscheidend wie bei den Tests des sicherheitsrelevanten Systems

Validierungssuite muss nicht besser sein als ein Test eines sicherheitsrelevanten Systems

gängige Praxis bei der Validierung von Compilern

Gen

Model

Code

Soll/Ist-Vergleich

Validierungssuite



Model basedTesting



Code (executable)



Analysis




Zwei Mal diversitäre Vorwärtsüber-setzung mit Ergebnisvergleich

Setzen G1 und G2 auf denselben Spezifikationen auf?

Können G1 und G2 wirklich unabhängig sein?

diversitäre Auslegung des Vergleichers? In der Luftfahrt wird diversitäre

Vorwärtsentwicklung im first und second level eingesetzt

doppelter Transformationsaufwand (Kosten)

Validierung der Ergebnisse bei jeder Übersetzung -> keine fehlenden Testfälle

G1

M

G2

C1 C2Vergleich



Model basedTesting



Code (executable)



Analysis




Vorwärts- und Rückwärtsübersetzungmit Vergleich des Ausgangsmaterials

Diversität durch unterschiedliche Aufgaben besser gegeben

Vergleich diversitär? Falls Transformation nicht eineindeutig ist,

kann M‘ nicht wiederhergestellt werden. Evtl. zusätzliche Hilfen notwendig, damit M‘

aus dem Code herstellbar ist. Vergleicher kann mit Intelligenz ausgestattet

werden (Äquivalenzvergleich) Validierung mit jeder Übersetzung. Fehler in V mit anschließender

Fehlerverschleierung in R relativ unwahrscheinlich -> sehr gute Fehleroffenbarung

V

M

R

Code

M’Vergleich



Model basedTesting



Code (executable)



Analysis




Generierung der Testfälle aus demModell mit Abdeckungsmessung

Generierte Testfälle nur für die Korrektheit des Generators (Gen)

Abdeckungsmessung soll die Güte der erzeugten Testfälle dokumentieren und nachweisen (optional).

Validierung mit jeder Übersetzung und Testausführung -> keine offenen Testfälle

Keine Funktionstests des Modells, die müssen noch gesondert formuliert und durchgeführt werden.

Gen

Model

Code

TestCase-Execution

Code-Coverage

Test-Case

Test-Gen



Model basedTesting



Code (executable)



Analysis




Applikationstest mit Abdeckungs-messung auf Ebene des Bytecodesoder Assemblers

Generierte Code wird mit Testfällen aus der Validierung abgedeckt

keine offene Funktionalität im Code vorhanden, da Testabdeckung gemacht

Test der Generierung wird mit den ohnehin notwendigen Funktionstests kombiniert -> Einsparung intensiver Generator-Tests

Abdeckungsmessungen können sehr aufwändig sein, bei sehr viel generiertem Code

Abdeckungsmessungen können manuelle Argumentation für nicht abgedeckte Testfälle haben -> aufwändig

Gen

Model

Code

TestCase-Execution

Code-Coverage

Valid. Test-Case



Model basedTesting



Code (executable)



Analysis




Generierung der Testfälle aus einemTestmodell mit anschließenderAbdeckungsmessung

ähnlich voriges Beispiel, allerdings werden die Testfälle aus einem separaten Testmodell erzeugt.

impliziter Funktionstest des Systems korrekte Generierung wird über die korrekte

Testausführung nachgewiesen doppelter Modellierungsaufwand (Modell +

Testmodell) Abdeckungsmessung weist Güte der

generierten Testfälle nach Abgleich zwischen Modell und Testmodell

kann anhand der Abdeckungsmessungen schwierig sein

Gen

Model

Code

TestCase-Execution

Code-Coverage

Test-Case

Test-Model

Test-Gen



Model basedTesting



Code (executable)



Analysis




Formal beweisbare Übersetzung

Korrektheit der Übersetzung anhand eines formalen Nachweises auf der Ebenen der Sprachdefinitionen

Formale Semantik der Sprachen notwendig

Evtl. aufwändige Nachweise notwendig

bisher noch keine industrielle Anwendung in der Breite möglich (Forschungsgegenstand)

Gen

Meta-M

Meta-C

FormalProof

Documents

Software in sicherheitsrelevanten Systemen