Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

1 Vorlesung "Software-Engineering" zVorige Vorlesung yAnalytische Qualitätssicherung yMetriken yTestverfahren zHeute: yFortsetzung: Testverfahren yKonstruktive.

Ähnliche Präsentationen


Präsentation zum Thema: "1 Vorlesung "Software-Engineering" zVorige Vorlesung yAnalytische Qualitätssicherung yMetriken yTestverfahren zHeute: yFortsetzung: Testverfahren yKonstruktive."—  Präsentation transkript:

1 1 Vorlesung "Software-Engineering" zVorige Vorlesung yAnalytische Qualitätssicherung yMetriken yTestverfahren zHeute: yFortsetzung: Testverfahren yKonstruktive Qualitätssicherung Prof. Ralf Möller, TUHH, Arbeitsbereich STS

2 2 Einordnung Planungsphase Lastenheft Definitionsphase Pflichtenheft Entwurfsphase Produktentwurf Implementierungsphase Produkt, Komponenten Abnahme und Einführung Installiertes Produkt Anforderungs- Definition Grobentwurf Modul- Implementierung Abnahmetest Systemtest Integrationstest Modultest Feinentwurf Anwendungsszenarien Testfälle

3 3 Testverfahren: Dynamische Verfahren zSoftware wird mit Testdaten ausgeführt zAusführung in realer Umgebung zPrinzip des Stichprobenverfahrens zNotwendigkeit zur Auswahl von Testfällen und Testdaten

4 4 Unterscheidung Testfälle - Testdaten zTestfall: yeine aus der Spezifikation oder dem Programm abgeleitete Menge von Eingabedaten zusammen mit den zugehörigen erwarteten Ergebnissen zTestdaten: yTeilmenge der Eingabedaten der Testfälle, mit denen das Programm tatsächlich ausgeführt wird

5 5 Kontrollflußbezogene Verfahren (1) zDarstellung der Programm(-teile) als Kontrollflußgraphen yAnweisungen (Anweisungsblöcke) als Knoten des Graphen yKontrollfluss als gerichtete Kanten zwischen Knoten yZweig: Einheit aus einer Kante und den dadurch verbundenen Knoten yPfad: Sequenz von Knoten und Kanten, die am Startknoten beginnt und am Endknoten endet x :=... ; y :=... IF x > 5 AND y < 2 THEN y := f(x,2) ELSE y := g(x,3) z :=... x :=... ; y :=... y := f(x,2) y := g(x,3) z :=...

6 6 Kontrollflussbezogene Verfahren (2) zPrinzip der "Überdeckung von Kontrollstrukturen" durch Testfälle (Coverage Analysis): yGezieltes Durchlaufen (von Teilen) der Kontrollstrukturen durch geeignete Gestaltung der Testfälle yAngestrebter/erreichter Überdeckungsgrad in Prozent angegeben

7 7 Arten der Überdeckung von Kontrollstrukturen zAnweisungsüberdeckung: yAlle Anweisungen werden mindestens einmal ausgeführt zZweigüberdeckung: yAlle Verzeigungen im Kontrollfluss werden mindestens einmal verfolgt zBedingungsüberdeckung: yAlle booleschen Wertekonstellationen von (Teil-) Bedingungen werden einmal berücksichtigt zPfadüberdeckung: yDurchlaufen aller Pfade von Start- zum Endknoten (außer bei sehr kleinen Programmen nur theoretisch möglich)

8 Validierung der Vollständigkeit von Testreihen anhand von Metriken Arten: Anweisungsüberdeckung (statement coverage) -> zu schwach Entscheidungsüberdeckung (branch coverage) -> minimum mandatory testing requirement Pfadüberdeckung (path coverage) -> in der Praxis nicht durchführbar Coverage Analysis

9 9 Datenflußbezogene Verfahren (1) zErweiterung der Kontrollflußgraphen um Datenflüsse zUnterscheidung verschiedener Situationen hinsichtlich des Zugriffs auf Variablen im Programm: yDefinition von Variablenwerten (Wertzuweisung) yBerechnende Benutzung (zur Ermittlung eines Wertes in Ausdrücken) yPrädikative Benutzung (Auswertung der Bedingungen in bedingten Anweisungen oder Schleifen)

10 10 Datenflußbezogene Verfahren (2) zPrinzip des Verfahrens: yFür jeden Definitionsknoten werden definitionsfreie Pfade zu allen Benutzungsknoten ermittelt yDie Auswahl der Testdaten muß das Durchlaufen jedes identifizierten definitionsfreien Pfades sicherstellen

11 11 Datenflußbezogene Verfahren (3) zDefinition von drei Funktionen als Basis der Datenflußverfahren: yFunktion def bildet jeden Knoten auf die Menge der darin global definierten Variablen ab yFunktion c-use ordnet jedem Knoten die in ihm berechnend benutzten Variablen zu yFunktion p-use weist jeder Kante die Menge von Variablen zu, deren prädikative Auswertung zum Durchlaufen der Kante notwendig ist  Definition der Menge du(v, n i ), wobei v  def(n i ):  du(v, n i ) enthält alle Knoten n j mit v  c-use(n j )  alle Kanten (n k, n l ) mit v  p-use((n k, n l )), wobei ein Pfad von n i nach n j bzw. n l existiert, auf dem v nicht neu definiert wird zAll-uses-Kriterium zur Auswahl von Testfällen  Für jeden Knoten und jede Variable v  def(n i ) wird mindestens ein definitionsfreier Pfad von n i zu allen Elementen von du(v, n i ) ausgeführt.

12 12 Funktionale Verfahren zÜberprüfung der in der Spezifikation festgelegten Funktionalität yProgrammstruktur irrelevant yBeste Grundlage: formale Spezifikation zBestimmung der Testdaten: yBildung "funktionaler Äquivalenzklassen": Eingabe- und Ausgabemengen, die jeweils zu einer (Teil-) Funktionalität gehören yAlle Werte einer Äquivalenzklasse verursachen ein identisches funktionales Verhalten eines Programms zAuswahl von Testdaten aus den Äquivalenzklassen: yZufällig yTest spezieller Werte (z.B. 0, nil) yGrenzwertanalyse (primär Grenzbereiche der Eingabemengen als Testdaten)

13 13 Testen von Moduln zAufdecken von Fehlern in der isolierten Modulrealisierung zModultest wird meist als Teilphase der Implementierung betrachtet zNotwendigkeit einer Testumgebung, die die anderen Module simuliert und das Modul selbst benutzbar macht (Fehler in Testumgebung?)

14 14 Testumgebungen z(Wiederholten) Aufruf des Testobjektes ermöglichen zEingabedaten für Testobjekt bereitstellen zExterne Ressourcen und deren Ergebnisse/Aktivitäten simulieren (z.B. importierte Module) zErgebnisse der Testausführung ausgeben und speichern

15 15 Testen von Modulverbindungen zTesten von Subsystemen (= Teilmengen von verknüpften Moduln) zPrüfung der Kommunikation zwischen den Moduln zSchrittweiser Aufbau größerer Subsysteme durch Hinzufügen weiterer Module/Subsysteme (inkrementelles Testen, Integrationstest) zAusführung meist Bottom-up, jedoch auch Top- Down-Vorgehensweise möglich zEbenfalls Testumgebung notwendig, "Stub"-Moduln bzw. Treiber-Moduln erforderlich

16 16 JUnit zFramework, um den Unit-Test eines Java- Programms zu automatisieren. zeinfacher Aufbau zleicht erlernbar Many thanks to Carrara Engineering for making their slides available:

17 17 Konstruktiver Ansatz zTestfälle werden in Java programmiert, keine spezielle Skriptsprache notwendig. zIdee ist inkrementeller Aufbau der Testfälle parallel zur Entwicklung. yPro Klasse wird mindestens eine Test-Klasse implementiert.

18 18 Simple Test Case [1/2] public class Money { private double amount; public Money(double amount) { this.amount = amount; } public double getAmount () { return amount; }

19 19 Simple Test Case [2/2] import junit.framework.*; public class MoneyTest extends TestCase { public MoneyTest(String name) { super(name); } public void testAmount() { Money money = new Money(2.00); assertEquals( " err-msg ", 2.00, money.getAmount()); } public static void main(String[] args) { junit.swingui.TestRunner.run(MoneyTest.class); }

20 20 Anatomie eines Testfalls [1/3]  Jede Testklasse wird von der Framework- Basisklasse junit.framework.TestCase abgeleitet. zJede Testklasse erhält einen Konstruktor für den Namen des auszuführenden Testfalls.

21 21 Anatomie eines Testfalls [2/3]  JUnit erkennt die Testfälle anhand des Signaturmusters public void testXXX() zDas Framework kann mit dem Java-Reflection- Package die Testfälle somit automatisch erkennen.

22 22 Anatomie eines Testfalls [3/3]  Die assertEquals Methode dient dazu, eine Bedingung zu testen.  Ist eine Bedingung nicht erfüllt, d.h. false, protokolliert JUnit einen Testfehler.  Der junit.swingui.TestRunner stellt eine grafische Oberfläche dar, um die Test kontrolliert ablaufen zu lassen.

23 23 Das JUnit-Framework

24 24 Assert [1/4]  Die Klasse Assert definiert eine Menge von assert Methoden, welche die Testklassen erben.  Mit den assert Methoden können unterschiedliche Behauptungen über den zu testenden Code aufgestellt werden. zTrifft eine Behauptung nicht zu, wird ein Testfehler protokolliert.

25 25 Assert [2/4]  asserTrue (boolean condition) verifiziert, ob einen Bedingung wahr ist.  assertEquals(Object expected, Object actual) verifiziert, ob zwei Objekte gleich sind. Der Vergleich erfolgt mit der equals Methode.  assertEquals(int expected, int actual) verifiziert, ob zwei ganze Zahlen gleich sind. Der Vergleich erfolgt mit dem == Operator.  assertNull(Object object) verifiziert, ob einen Objektreferenz null ist.

26 26 Assert [3/4]  assertEquals(double expected, double actual, double delta) verifiziert, ob zwei Fliesskommazahlen gleich sind. Da Fliesskommazahlen nicht mit unendlicher Genauigkeit verglichen werden können, kann mit delta ein Toleranzwert angegeben werden.  assertNotNull(Object object) verifizert, ob eine Objetkreferenz nicht null ist. Es existieren überladene Methoden mit einer Zeichenkette als erstem Argument für die Angabe der Fehlermeldung im Protokoll.

27 27 Assert [4/4]  assertSame(Object expected, Object actual) verifizert, ob zwei Referenzen auf das gleiche Objekt verweisen.  Für die primitiven Datentypen float, long, boolean, byte, char und short existieren ebenfalls assertEquals Methoden.

28 28 Testen von Exceptions [1/2]  Exceptions werden in Java mit dem catch Block behandelt.  Mit der Methode fail aus der Assert Klasse wird ein Testfehler ausgelöst und protokolliert.

29 29 Testen von Exceptions [2/2]  Im vorliegenden Beispiel wird beim Aufruf des Konstruktors der Klasse MyClass mit einer negativen Zahl die IllegalArgumentEcxeption ausgelöst. try { new MyClass(-10); fail(“Meine Meldung im Fehlerfall“); catch (IllegalArgumentException e) { }

30 30 TestFixture [1/2] zEin Testfall sieht in der Regel so aus, dass einen bestimmte Konfiguration von Objekten aufgebaut wird, gegen die der Test läuft. zDiese Menge von Testobjekten wird auch als Test-Fixture bezeichnet. zDamit fehlerhafte Testfälle nicht andere Testfälle beeinflussen können, wird die Test-Fixture für jeden Testfall neu initialisert.

31 31 TestFixture [2/2]  In der Methode setUp werden Instanzvariablen initialisiert.  Mit der Methode tearDown werden wertvolle Testressourcen wie zum Beispiel Datenbank- oder Netzwerkverbindungen wieder freigegeben.

32 32 Beispiel TestFixture import junit.framework.*; public class MoneyTest extends TestCase { private Money money;... protected void setUp() { money = new Money(2.00); } protected void tearDown() { } public void testAmount() { assertTrue( " err-msg ", 2.00 == money.getAmount()); }...

33 33 Lebenszyklus eines Testfalls  Testklasse MoneyTest mit Methoden testAdding und testAmount. ynew MoneyTest(“testAdding“) ysetUp() ytestAdding() ytearDown() yNew MoneyTest(“testAmount“) ysetUp() ytestAmount() ytearDown()

34 34 TestSuite [1/5] zUm eine Reihe von Tests zusammen ausführen zu können, werden die Tests zu TestSuites zusammengefasst.  Eine Suite von Test wird dabei durch ein TestSuite Objekt definiert. zMit JUnit können beliebig viele Test in einer TestSuite zusammengefasst werden.

35 35 TestSuite [2/5]  Um eine Testsuite zu definieren, ist ein TestSuite Objekt zu bilden und mittels der addTestSuite Methode verschiedene Testfallklassen hinzuzufügen.  Jede Testfallklasse definiert implizit eine eigene suite Methode, in der alle Testfallmethoden der betreffenden Klasse eingebunden werden. [Reflection Package]

36 36 TestSuite [3/5] import junit.framework.*; public class AllTests { public static Test suite() { TestSuite suite = new TestSuite(); suite.addTestSuite(MoneyTest.class); suite.addTestSuite(Formater.class); suite.addTestSuite(TestSheet.class); return suite; }

37 37 TestSuite [4/5] zDamit beliebig viele TestCase und TestSuite Objekte zu einer umfassenden TestSuite- Hierarchie kombiniert werden kann, wird das Composite- Pattern verwendet.

38 38 TestSuite [5/5] zIn vielen Fällen ist es praktisch, pro Package eine TestSuite-Klasse zu definieren.  Es hat sich eingebürgert diese Klasse AllTest zu nennen.

39 39 Beispiel AllTests – Einbindung von Test-Klassen package com.iq.htmlFormatter; import junit.framework.*; public class AllTests { public static Test suite() { TestSuite suite = new TestSuite("htmlFormatter"); suite.addTestSuite(SpacerTest.class); suite.addTestSuite(LevelTest.class); return suite; } public static void main (String[] args) { junit.swingui.TestRunner.run(AllTests.class); }

40 40 Beispiel AllTests – Einbindung von AllTests-Klassen package com.iq.html; import junit.framework.*; public class AllTests { public static Test suite() { TestSuite suite = new TestSuite("Package html"); suite.addTest(com.iq.html.tag.AllTests.suite()); return suite; } public static void main (String[] args) { junit.swingui.TestRunner.run(AllTests.class); }

41 41 Testausführung  In vielen Fällen ist es praktisch, pro AllTests Klasse eine main Methode zu definieren, welche die graphische Benutzeroberfläche aufruft und die eigene Klasse als Parameter übergibt. public static void main (String[] args) { junit.swingui.TestRunner.run(AllTests.class); }

42 42 Zusammenfassung zJunit yEinfaches Framework für den Unit-Test von Java- Programmen. yTestfälle werden parallel zum eigentlichen Code entwickelt. yDie Tests können vollautomatisch ausgeführt werden.

43 43 Qualitätssicherung durch Tests zEin Test ist prinzipiell nur geeignet, evtl. vorhandene Fehler eines Systems zu Tage treten zu lassen, nicht jedoch die Abwesenheit von Fehlern zu zeigen (vgl. Verifikation) zDer Überdeckungsgrad ist ein Maß für den Grad der Vollständigkeit eines Tests zEin Regressionstest ist ein Testverfahren, bei dem eine Sammlung von Testfällen erstellt wird, die bei Änderungen am System (automatisch) erneut überprüft werden zBei einer Individualsoftware findet ein Abnahmetest statt zBeim Alpha-Test für Standardsoftware wird das System in der Zielumgebung des Herstellers durch ausgewählte Anwender erprobt zBeim Beta-Test für Standardsoftware wird das System bei ausgewählten Zielkunden in einer eigenen Umgebung zur Probenutzung zur Verfügung gestellt. Auftretende Probleme und Fehler werden protokolliert. Beta-Tester erhalten typischerweise einen Preisnachlaß auf das endgültige Produkt. Typischerweise werden Beta-Tests iterativ mit aufeinanderfolgenden "release candidates" (RC) durchgeführt.

44 44 Testen: Zusammenfassung zRolle der Spezifikation beim Test zTestsystematik zReproduzierbarkeit von Tests (insbesondere nach Änderungen) zTests decken Fehler auf zTests helfen nicht, Fehler zu vermeiden zHerstellungsprozeß bedeutsam: -> Qualitätsmanagement, konstruktive Verfahren

45 45 Konstruktive Verfahren zAnnahme: Die Qualität eines Produktes wird maßgeblich durch die Qualität des Herstellungsprozesses bestimmt yQualität ins Bewußtsein der Projektmitglieder bringen yRückverfolgbarkeit gewährleisten yVerantwortlichkeiten und Zuständigkeiten schaffen (Planstellen) y-> Organisatorischen Rahmen für Software-Herstellungsprozeß schaffen

46 46 ISO 9000 ( erstmals standardisiert 1987) zDas ISO 9000 Normenwerk legt für ein Auftraggeber-Lieferanten-Verhältnis einen allgemeinen, übergeordneten, organisatorischen Rahmen zur Qualitätssicherung von Produkten (insbesondere ISO 9001). zGeprägt durch industrielle Fertigung von Produkten, aber ausgeweitet auf Erstellung von Software (9000-3) zZertifizierung nach 9001 bzw durch Zertifizierungsstelle, wenn ein Qualitäts-managementsystem vorhanden. zZertifiziert wird der Herstellungsprozeß, NICHT DAS PRODUKT

47 47 ISO Struktur (1) [Balz98]

48 48 ISO Struktur (2) [Balz98]

49 49 ISO zAufbau ISO : yRahmen yLebenszyklustätigkeiten yUnterstützende Tätigkeiten zInhalt ISO : yEntwicklung yLieferung yWartung von Software z Maßnahmen: yder Geschäftsführung yder Mitarbeiter der Qualitätssicherung z Anwendungsformen: yDarlegung der Qualitätssicherung gegenüber Dritten yAufbau und Verbesserung eines QS-Systems

50 50 ISO Implizites Vorgehensmodell [Balz98]

51 51 ISO Implizites Vorgehensmodell [Balz98]

52 52 ISO Implizites Vorgehensmodell zPhasenunabhängige Tätigkeiten: yKonfigurationsmanagement: xIdentifikation und Rückverfolgbarkeit d. Konfiguration xLenkung von Änderungen xKonfigurations-Statusbericht yLenkung der Dokumente yQualitätsaufzeichungen yMessungen und Verbesserungen: xam Produkt xdes Prozesses yFestlegung von Regeln, Praktiken und Übereinkommen für den Einsatz eines Qualitätsmanagementsystems yNutzung von Werkzeugen und Techniken, um QS-Leitfaden umzusetzen yUnterauftragsmanagement

53 53 ISO Bewertung zVorteile: zAufmerksamkeit auf Qualitätssicherung zExterne Zertifizierung und Wiederholung d. Audit zFestlegen von Anforderungen zErleichtert die Akquisition von Aufträgen zWeniger Produkthaftungsrisiko zStärkung Qualitätsbewußtsein z Nachteile: z Unsystematischer Aufbau z Keine sauber Trennung zwischen fachlichen, Management- und QS- Aufgaben z Gefahr Software-Bürokratie z Gefahr mangelnde Flexibilität z Hoher Aufwand für Einführung und Pflege

54 54 Andere Modelle zTQM (Total Quality Management) zCMM (Capability Maturity Model) zSPICE (Software Process Improvement and Capability dEtermintation) zSiehe: Balzert, Lehrbuch der Softwaretechnik Band 2

55 55 Was kommt beim nächsten Mal?


Herunterladen ppt "1 Vorlesung "Software-Engineering" zVorige Vorlesung yAnalytische Qualitätssicherung yMetriken yTestverfahren zHeute: yFortsetzung: Testverfahren yKonstruktive."

Ähnliche Präsentationen


Google-Anzeigen