ppt - Institut für Informatik

 Documents

 116 views
of 16
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Description
Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt…
Share
Transcript
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 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 H. Schlingloff, Software-Engineering II 18.1.2006 Folie 2 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 H. Schlingloff, Software-Engineering II 18.1.2006 Folie 3 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 H. Schlingloff, Software-Engineering II 18.1.2006 Folie 4 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 H. Schlingloff, Software-Engineering II 18.1.2006 Folie 5 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 H. Schlingloff, Software-Engineering II 18.1.2006 Folie 6 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 H. Schlingloff, Software-Engineering II 18.1.2006 Folie 7 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 H. Schlingloff, Software-Engineering II 18.1.2006 Folie 8 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“) H. Schlingloff, Software-Engineering II 18.1.2006 Folie 9 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 H. Schlingloff, Software-Engineering II 18.1.2006 Folie 10 Ein Beispiel public final class IMath { /** A class to test the class IMath. */ public class IMathTest{ /* /** Runs the tests. */ * Returns an integer approximation public static void main(String[] args) { * to the square root of x. printTestResult(0); */ printTestResult(1); public static int isqrt(int x) { printTestResult(2); int guess = 1; printTestResult(3); while (guess * guess < x) { printTestResult(4); guess++; printTestResult(7); printTestResult(9); } printTestResult(100); return guess; } } private static void printTestResult(int arg) { } System.out.print(“isqrt(“ + arg + “) ==> “); System.out.println(IMath.isqrt(arg)); } } Beispiel: Yoonsik Cheon, University of Texas at El Paso, www.cs.utep.edu/~cheon/cs3331/notes/unit-testing.ppt H. Schlingloff, Software-Engineering II 18.1.2006 Folie 11 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? H. Schlingloff, Software-Engineering II 18.1.2006 Folie 12 JUnit import junit.framework.*; • Kontrollierte public class IMathTest extends TestCase { Testausführung und - public void testIsqrt() { auswertung assertEquals(0, IMath.isqrt(0)); assertEquals(1, IMath.isqrt(1)); • Public domain … (www.junit.org) assertEquals(10, IMath.isqrt(100)); • sofort einsetzbar, in } viele IDEs integriert public static Test suite() { return new TestSuite(IMathTest.class); • unterstützt „Test } durch Entwickler“ public static void main (String[] args) { Paradigma junit.textui.TestRunner.run(suite()); • Testautomatisierung! } } H. Schlingloff, Software-Engineering II 18.1.2006 Folie 13 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) H. Schlingloff, Software-Engineering II 18.1.2006 Folie 14 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) H. Schlingloff, Software-Engineering II 18.1.2006 Folie 15 Pause! ESA: „Testing successfully completed“ http://www.esa.int/images/Cartoon-vib-test_L.gif H. Schlingloff, Software-Engineering II 18.1.2006 Folie 16
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks