Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

25.1.2006 Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt.

Ähnliche Präsentationen


Präsentation zum Thema: "25.1.2006 Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt."—  Präsentation transkript:

1 Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer Institut für Rechnerarchitektur und Softwaretechnik

2 Folie 2 H. Schlingloff, Software-Engineering II Überblick 1. Eingebettete Systeme 1.1. Definitionen 1.2. Anforderungsanalyse 1.3. Modellierung 1.4. Architektur 1.5. Automotive Software Engineering 2. Software-Qualität 2.1 Definitionen und Standards 2.2 Funktionstest, Überdeckungsmaße 2.3 Integrations-, HiL- und Abnahmetests 2.4 Verifikation und Validierung 3. Projektmanagement

3 Folie 3 H. Schlingloff, Software-Engineering II Integrationstest Ziel: Systematische Erprobung des korrekten Zusammenspiels von Modulen Modultest auf höherer Abstraktionsebene White-Box auf Modulebene Komponenten und Verbindungen sind sichtbar Vorbedingung: die elementaren Module sind gut getestet; man kann annehmen, dass sie weitgehend fehlerfrei sind (neu auftretende Fehler sind auf Inkompatibilitäten zwischen den Modulschnittstellen zurückzuführen) Methode: Platzhalter und Treiber Modul A Modul F Modul C Modul DModul B Modul E

4 Folie 4 H. Schlingloff, Software-Engineering II Platzhalter (stubs, Stümpfe) Ein Platzhalter (stub) ist ein Pseudo-Modul, der die Funktionalität einer noch nicht geschriebenen oder integrierten Komponente (partiell) emuliert Implementierungsmöglichkeiten z.B. Rückgabe eines konstanten Wertes statt eines berechneten Funktionswertes z.B. Anzeigen der Eingabewerte und Zurückgeben von vom Benutzer eingegebener Werte z.B. Erzeugung von schnellen Prototypen oder schlecht synthetisierten Funktionen, die mit wenig Aufwand erstellt werden kann (Wegwerfsoftware)

5 Folie 5 H. Schlingloff, Software-Engineering II Beispiel Taschenrechner Funktionalität: wissenschaftlich-technischer Rechner, Speicher, Anzeige-Scrolling, programmierbare Funktionen, grafisches Display (für Funktionsplot) Systemarchitektur? Stubs?

6 Folie 6 H. Schlingloff, Software-Engineering II Treiber und Orakel Ein Treiber ist ein Modul welches ein zu testendes Modul (IUT, Implementation under Test) aufruft und mit Eingabedaten versorgt Orakelproblem: Entscheidung ob die von der IUT zurück gelieferten Werte korrekt sind lösbar: automatische Testauswertung im Treiber unlösbar: manuelle Bewertung der Tests Beispiele für lösbare bzw. unlösbare Orakelprobleme Treiber zum Test einer Additionsfunktion sende i, prüfe ob Turingmaschine i terminiert wird ein Programmtext korrekt übersetzt? Erfolgt die Berechnung innerhalb einer Millisekunde?

7 Folie 7 H. Schlingloff, Software-Engineering II Ergebnisse Integrationstest Was kann bei der Integration schiefgehen? undokumentierte Seiteneffekte Eigenschaften des Betriebssystems, Speicherlecks Parallelität, Verklemmungen Kommunikationsverzögerungen Oft wird für die Integration zusätzliche glueware benötigt, die nicht im Modultest getestet wurde

8 Folie 8 H. Schlingloff, Software-Engineering II Beispiel: Taschenrechner Welche Testtreiber werden benötigt? Welche Tests sollen in welcher Reihenfolge durchgeführt werden? Entwerfen Sie ein Konzept für die Integrationstests jetzt!

9 Folie 9 H. Schlingloff, Software-Engineering II Systemtest (1) Möglichkeiten: Big-Bang, Top-down, Bottom-Up, Sandwich Big-Bang Alle individuellen Komponenten werden an einem Tag zusammengesetzt und getestet Klingt verwegen, ist aber manchmal nicht anders machbar (z.B. wegen Verfügbarkeit spezieller Ressourcen, organisatorische Trennung zwischen Testphasen nicht möglich o.ä.) Top-Down Platzhalter für alle Komponenten vorbereitet Übergeordnetes Modul wird mit Platzhaltern getestet diese werden einer nach dem anderen durch untergeordnete Module ersetzt - breadth-first oder depth-first während die Module integriert werden, müssen einige Tests erneut durchgeführt werden (Regressionstest)

10 Folie 10 H. Schlingloff, Software-Engineering II Systemtest (2) Bottom-Up Treiber für alle Komponenten vorbereitet Basismodule werden in sogenannte Builds gruppiert und integriert idealerweise wertet der Treiber die Ergebnisse der Testläufe aus Treiber werden nach und nach ersetzt, Funktionsumfang wächst ständig Sandwichmethode Zusammenwachsen des Systems von oben und unten Stümpfe für übergeordnete Module, Treiber für Basismodule Platzhalter bzw. Treiber werden bedarfsgerecht (in Abhängigkeit der Testphase) ersetzt Modul A Modul F Modul C Modul DModul B Modul E

11 Folie 11 H. Schlingloff, Software-Engineering II Vor- und Nachteile (1) Big-bang keinerlei Zusatzaufwand für Treiber/Platzhalter unsystematische Methode, Test problematisch Fehlerlokalisation evtl. schwierig inkrementell Integration bei Fertigstellung der Komponente möglich Testfälle können vergleichsweise einfach konstruiert werden, Testüberdeckung kann gewährleistet werden Gegebenenfalls viele Testtreiber/Platzhalter nötig

12 Folie 12 H. Schlingloff, Software-Engineering II Vor- und Nachteile (2) Top-down frühe Verfügbarkeit des Systems aus Benutzersicht (Prototyp) Verzahnung von Entwurf und Implementierung schwierige Implementierung der Platzhalter mit zunehmender Integrationstiefe Schwierigkeiten bei der Konstruktion von Testfällen für tiefer liegende Komponenten Zusammenspiel der Systemsoftware, Hardware und Anwendungsebene wird erst sehr spät getestet Bottom-up keine Platzhalter nötig Testbedingungen leicht herstellbar Testergebnisse einfach zu interpretieren Fehleingaben zur Prüfung der Ausnahmebehandlung lauffähiges Gesamtsystem erst sehr spät verfügbar Fehler in der Produktdefinition werden spät erkannt, können zu umfangreichen Änderungen führen

13 Folie 13 H. Schlingloff, Software-Engineering II Pause!

14 Folie 14 H. Schlingloff, Software-Engineering II Test eingebetteter Software

15 Folie 15 H. Schlingloff, Software-Engineering II

16 Folie 16 H. Schlingloff, Software-Engineering II HiL-Tests Test realer Steuergeräte (-verbünde) Zielsoftware läuft auf Zielhardware Simulation der Strecke in Echtzeit Sensorik, Aktuatorik, Loop Umgebungsmodell teilweise sehr komplex (Handelsobjekt!) Schnittstellenanpassung, I/O-Karten ggf. auch Simulation anderer Steuergeräte Testsystem arbeitet Testsuite ab Vorspielen von Dateien mit Verläufen der Stimuli Aufzeichnen von Dateien mit Verläufen der Reaktionen

17 Folie 17 H. Schlingloff, Software-Engineering II HiL-Aufbau Implementierungssoftware Modelle auf dem Simulator Experiment-Kontrolle Skripte oder graphisch Animation der Ergebnisse Streckenmodelle kommerziell oder proprietär HiL-Hardware Prozessorkarte(n), I/O, flexibele Stromversorgung (versch. Spannungsebenen) Anschlüsse für Steuergerät Fehlerinjektionsmöglichkeit Bilder. dSPACE GmbH

18 Folie 18 H. Schlingloff, Software-Engineering II HiL-Tests Vorteile von HiL-Tests Testabdeckung auch wenn reale Umgebung fehlt / nicht verfügbar (z.B. Glatteis, Schwerelosigkeit) gezielte Herbeiführung von Grenzsituationen automatisches Durchschreiten von Parametersätzen Nachbildung von im Feldversuch aufgetretenen Auffälligkeiten Probleme Aufwändige Hardware und Streckenmodellierung Schnittstellen müssen jedesmal neu angepasst werden Spezifikation von Sollverhalten, Testauswertung


Herunterladen ppt "25.1.2006 Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt."

Ähnliche Präsentationen


Google-Anzeigen