Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

18.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: "18.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 Übersicht 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 HiL-, Integrations- und Abnahmetests 2.4 Verifikation und Validierung

3 Folie 3 H. Schlingloff, Software-Engineering II 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 Folie 4 H. Schlingloff, Software-Engineering II 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 Folie 5 H. Schlingloff, Software-Engineering II 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 Folie 6 H. Schlingloff, Software-Engineering II 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 Folie 7 H. Schlingloff, Software-Engineering II 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 Folie 8 H. Schlingloff, Software-Engineering II 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 Folie 9 H. Schlingloff, Software-Engineering II 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 Folie 10 H. Schlingloff, Software-Engineering II 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 Folie 11 H. Schlingloff, Software-Engineering II Ein Beispiel Beispiel: Yoonsik Cheon, University of Texas at El Paso, 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; } /** 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)); }

12 Folie 12 H. Schlingloff, Software-Engineering II 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 Folie 13 H. Schlingloff, Software-Engineering II JUnit Kontrollierte Testausführung und - auswertung Public domain (www.junit.org) sofort einsetzbar, in viele IDEs integriert unterstützt Test durch Entwickler Paradigma Testautomatisierung! 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()); }

14 Folie 14 H. Schlingloff, Software-Engineering II 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 Folie 15 H. Schlingloff, Software-Engineering II 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 Folie 16 H. Schlingloff, Software-Engineering II Pause! ESA: Testing successfully completed


Herunterladen ppt "18.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