Prof. Dr. Holger Schlingloff

Präsentation zum Thema: "Prof. Dr. Holger Schlingloff"—  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 Übersicht 1. Eingebettete Systeme 2. Software-Qualität
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 HiL-, Integrations- und Abnahmetests 2.4 Verifikation und Validierung

3 Test = systematische Qualitätsprobe
Experimentieren = Ausführen einzelner Versuche zur Erlangung einer neuen Erkenntnis Probieren = experimentelles Feststellen der Qualität eines Objekts Testen = systematisches Probieren nach verschiedenen Qualitätskriterien (oft: Korrektheit) Prüfen = Testen einer Serie gleichartiger Objekte Verifizieren = Nachweisen der Korrektheit einer Implementierung Validieren = Nachweisen der Adäquatheit einer Spezifikation

4 Testen: Pragmatik Testen ist das systematische Ausführen von Software mit dem Ziel, Fehler zu finden Test der Korrektheit nur mit Spezifikation Test erfolgreich  Fehler gefunden „Testing can never show the absence of failures“ (Dijkstra) aber: das kann auch keine andere Methode Testen kann die Zahl der enthaltenen Fehler reduzieren Softwareentwicklung konstruktiv, -test destruktiv? in gewisser Hinsicht ja, aber es erfordert viel Kreativität, die Denkmuster und –fehler anderer Menschen zu durchschauen

5 Testen: Systematik Internwissen über Testobjekt
Codebasierte Tests, Grey- und Blackbox-Tests Phase oder Systemstruktur Modultest, Integrationstest, Abnahmetest Methodentest, Klassentest, Komponententest, Systemtest Ziel Funktionstest, Schnittstellen- und Interoperabilitätstests, Oberflächen- und Benutzbarkeitstests, Last- und Stresstests Ausführung manuelle oder automatisierte Tests, Self-Tests Regressionstests, Produktlinientest

6 Test eingebetteter Systeme
besonders wichtig, da oftmals sicherheitskritisch keine bzw. schlechte Aktualisierungsmöglichkeiten besonders aufwändig 50-80% im Gegensatz zu 30-40% besonders schwierig Realzeitproblematik Zulieferer-/Hersteller-Problematik

7 2.2 Funktionstests, Überdeckungen
Test der spezifizierten Funktionalität Konzentration auf funktionale Anforderungen Ein- / Ausgaberelation reaktives Verhalten des Systems keine Berücksichtigung nichtfunktionaler Anforderungen Leistungskriterien (Zeit, Menge, Durchsatz) besondere Qualitäten (Benutzbarkeit, Änderbarkeit, …) Randbedingungen (Plattformen, Gesetze, Traditionen, …) Phasen des Funktionstests Modul- oder Komponententest Integrations- und Systemtests

8 Modul- oder Komponententest
erste Teststufe im analytischen Teil des V-Modells erstmaliger Test der ausführbaren Softwarebausteine nach der Programmierung Prozeduren, Funktionen (imperativ) Module, Units, Klassen, Interfaces (objektorientiert) Blöcke (in der modellbasierten Entwicklung) Bausteine dürfen auch verschachtelt sein Jeder einzelne Baustein wird unabhängig von den anderen getestet keine externen Einflüsse oder Wechselwirkungen klare Fehlereingrenzung und -lokalisierung

9 Vorgehensweise Konzentration auf Aufdeckung von Fehlern im Modul
falsche Berechnungen fehlende Programmpfade, Sonderfallbehandlung unzulässige Ein- und Ausgabewerte Robustheit gegenüber falscher Benutzung sinnvolle Fehlermeldungen bzw. Ausnahmebehandlung Bottom-up Ansatz Start mit Klassen die von keinen anderen abhängen Alle Funktionen der Klasse müssen getestet werden, alle Datenfelder verwendet und alle Zustände durchlaufen werden Dann Test von Klassen die auf bereits getesteten aufbauen Schichtenartige Architektursicht; Aggregation von Einzeltests („Testfällen“) in Gruppen („Testsuiten“)

10 testgetriebene SW-Entwicklung
Wann soll man Modul-Tests schreiben? Wenn die Klasse fertig ist? testen bevor andere damit konfrontiert werden Parallel zur Implementierung der Klasse? testen um eigene Arbeit zu erleichtern Vor der Implementierung der Klasse („eXtreme Programming“) Tests während Implementierung immer verfügbar Konzentration auf Interface statt Implementierung durch Nachdenken über Testfälle Design-Fehler finden Wer soll die Unit-Tests erstellen? üblicherweise: der Programmierer aber: für die eigenen Fehler ist man blind

11 Ein Beispiel public final class IMath { /*
/** A class to test the class IMath. */ public class IMathTest{ /** Runs the tests. */ public static void main(String[] args) { printTestResult(0); printTestResult(1); printTestResult(2); printTestResult(3); printTestResult(4); printTestResult(7); printTestResult(9); printTestResult(100); } private static void printTestResult(int arg) { System.out.print(“isqrt(“ + arg + “) ==> “); System.out.println(IMath.isqrt(arg)); public final class IMath { /* * Returns an integer approximation * to the square root of x. */ public static int isqrt(int x) { int guess = 1; while (guess * guess < x) { guess++; } return guess; Beispiel: Yoonsik Cheon, University of Texas at El Paso,

12 Fragen zum Beispiel Was ist die Ausgabe der Tests?
Vorteile gegenüber manuellem Test? Welche Fehler werden (nicht) gefunden? Probleme mit dieser Art zu testen? Was kann verbessert werden?

13 JUnit Kontrollierte Testausführung und -auswertung
import junit.framework.*; public class IMathTest extends TestCase { public void testIsqrt() { assertEquals(0, IMath.isqrt(0)); assertEquals(1, IMath.isqrt(1)); … assertEquals(10, IMath.isqrt(100)); } public static Test suite() { return new TestSuite(IMathTest.class); public static void main (String[] args) { junit.textui.TestRunner.run(suite()); Kontrollierte Testausführung und -auswertung Public domain ( sofort einsetzbar, in viele IDEs integriert unterstützt „Test durch Entwickler“ Paradigma Testautomatisierung!

14 JUnit Ausführungsmodell
Vor jedem Test wird setUp() aufgerufen (Erzeugung und Initialisierung von Objekten) Aufruf der Methode testXXX, die prinzipiell beliebige Aktionen ausführen kann Testverdikt mittels Zusicherungen (assert…) Aufruf von tearDown() (Destruktor) Zusammenfassen der testXXX-Methoden in der suite() Ausführung der suite() durch main() Falls alle Zusicherungen bei der Ausführung erfüllt sind, „läuft die Testsuite durch“ (alles grün); andernfalls wird eine Ausnahme geworfen und vom Testrahmen abgefangen (Testfall rot)

15 xUnit JUnit ist typisch für eine Reihe ähnlicher Tools
Vorteile der Verwendung automatisierte, wiederholbare Tests (nach jedem „Build“!) kombinierbar zu Testklassen und Testsuiten Einbeziehung von Testdaten automatische Testauswertung Möglichkeit des Tests von Ausnahmen Möglichkeit der Verwendung interner Schnittstellen Was JUnit dem Tester nicht abnimmt Testentwurf (Auswahl und Beurteilung der Testfälle)

16 Pause! ESA: „Testing successfully completed“ 18.1.2006