ppt - Institut für Informatik

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.
1.2.
1.3.
1.4.
1.5.
Definitionen
Anforderungsanalyse
Modellierung
Architektur
Automotive Software Engineering
2. Software-Qualität
2.1
2.2
2.3
2.4
Definitionen und Standards
Funktionstest, Überdeckungsmaße
HiL-, Integrations- und Abnahmetests
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 {
/*
* 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));
}
}
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.*;
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());
}
}
H. Schlingloff, Software-Engineering II
• 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
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