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 18.1.2006

Ü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 18.1.2006

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 18.1.2006

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 18.1.2006

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 18.1.2006

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 18.1.2006

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 18.1.2006

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 18.1.2006

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“) 18.1.2006

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 18.1.2006

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, www.cs.utep.edu/~cheon/cs3331/notes/unit-testing.ppt 18.1.2006

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

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 (www.junit.org) sofort einsetzbar, in viele IDEs integriert unterstützt „Test durch Entwickler“ Paradigma Testautomatisierung! 18.1.2006

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

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

Pause! ESA: „Testing successfully completed“ 18.1.2006 http://www.esa.int/images/Cartoon-vib-test_L.gif 18.1.2006