Qualitätssicherung von Software

Ähnliche Dokumente
Softwaretest. Methoden, Werkzeuge, Vorgehensweisen. Prof. Dr. Holger Schlingloff. Humboldt-Universität zu Berlin und.

Systemen - Literatur. Literatur. Literatur. Grundlegende Literatur

JUnit - Test Driven Development. Bernhard Frey, Thorsten Stratmann, Jackson Takam, Michel Müller 1

P r a k t I s c h e SOFTWARETECHNIK. Systemen - Literatur Dr. Klaudia Dussa-Zieger Testen von Software-Systemen SS 2007 (1)

Qualitätssicherung von Software

Qualitätssicherung von Software (SWQS)

Unit Tests in der Testgetriebenen Entwicklung

Swp08-6 Verantwortliche: Yundensuren, Baigalmaa. Testkonzept

Thema: Testen von objektorientierter Software

Programmiertechnik II

Das Test-Framework JUnit ETIS SS04

Testen mit JUnit. Apcon Workplace Solutions Member of itelligence. Testen von Java-Code mit JUnit. ÿstruktur eines Testfalls

Software-Engineering Software-Management

Test-Driven Design: Ein einfaches Beispiel

Testen. SEPR Referat: Testen - Oliver Herbst

Klassen von Testfällen. 3. Äquivalenzklassentests. Äquivalenzklassenbildung. Beispiele für Äquivalenzklassen von Eingaben

VU Softwarequalitätssicherung tssicherung WS2006 Testen von Softwaresystemen. Mag. Dipl.-Ing. Denis Frast

Testen mit JUnit. Martin Wirsing. Ziele. in Zusammenarbeit mit Michael Barth, Philipp Meier und Gefei Zhang

Funktionale Testverfahren. Black Box-Tests. Unsystematisches Testen. Unsystematisches Testen (2) Überblick:

Qualitätssicherung von Software

Testen - Konzepte und Techniken

Fortgeschrittenes Programmieren mit Java. Test Driven Development

Test-Strategien. Grundsätzliches Blackbox-Testen Whitebox-Testen Graybox-Testen Ablauf von Tests Zusammenfassung. HS Mannheim

Agilität und systematischer Test

Einfaches Programmtesten

Qualität von Software - Prof. Schlingloff, Lackner - SS2013 DYNAMISCHER TEST. Whitebox Testen mit JUnit

Code verifizieren mittels

Programmierung 2 Studiengang MI / WI

Unit Tests. Programmiermethodik. Eva Zangerle Universität Innsbruck

Testen Prinzipien und Methoden

Das automatisierte Testen mit JUnit

Testphase. Das Testen

Software-Test: Funktionstest

Unit Tests mit Junit 4. Dario Borchers

Software Engineering in der Praxis

Testen von Softwaresystemen. 13. Januar 2015

Info: Standard DO-178B. 5. Mocking. Zusammenspiel von Klassen testen. Allgemein: Klassen testbar machen

Teststrategie festlegen und Teststufen aufeinander abstimmen

Vorkurs Informatik WiSe 15/16

Allgemein: Klassen testbar machen. 5. Mocking. Mocks programmieren. Zusammenspiel von Klassen testen

II. Grundlagen der Programmierung. 9. Datenstrukturen. Daten zusammenfassen. In Java (Forts.): In Java:

Testmanagement. Dirk Tesche

II.1.1. Erste Schritte - 1 -

Programmieren I. Übersicht. Vorlesung 12. Handout S. 1. Martin Schultheiß. Hochschule Darmstadt Wintersemester 2010/2011

Komponenten-basierte Entwicklung Teil 6: Einführung in JUnit

Komponententest. Testen von Software Systemen. Übung 02 SS 2009 Version:

Grundlagen der Programmierung Prof. H. Mössenböck. 14. Schrittweise Verfeinerung

Markus Wichmann. Testen von Java Code mit. JUnit

Der EMF-generierte Code. 7. November 2012

Java für C++ Programmierer

1. Motivation 2. Begriffsklärung 3. Komponententests 4. Integrationstests 5. Integrationsstrategien 6. Zusammenfassung

Programmiertechnik. Prof. Dr. Oliver Haase Raum G124 Tel: 07531/ Oliver Haase Hochschule Konstanz 1

Teil 1: Grundeigenschaften von Rechnern und Software

Java Schulung. Objektorientierte Programmierung in Java Teil IV: Testen mit JUnit. Prof. Dr. Nikolaus Wulff

Testen von Software. Dr. Stefan Hanenberg Universität Duisburg-Essen. Universität Osnabrück, Motivation und grundlegende Eigenschaften

Java Einführung Programmcode

5. Tutorium zu Programmieren

Praktikum Informatik II Prof. Dr. Martin Trauth, Dr. Michael Männel

Prozess-Modelle für die Softwareentwicklung

Beuth Hochschule Java-Testprogramme mit JUnit schreiben WS11/12

Catch the Bug Testaktivitäten erfolgreich messen

Java Einführung VARIABLEN und DATENTYPEN Kapitel 2

Java Einführung Abstrakte Klassen und Interfaces

Programmieren I. Strategie zum Entwurf von Klassen. Beispiele. Design von Klassen. Dr. Klaus Höppner. Beispiel: Bibliothek

Testen mit JUnit. Motivation

Systematische Testfallableitung und Tests durchführen

Programmierprojekt. Anne0e Bieniusa Sommersemester 2014

Das erste Programm soll einen Text zum Bildschirm schicken. Es kann mit jedem beliebigen Texteditor erstellt werden.

Programmieren I. Die Programmiersprache Java. Institut für Angewandte Informatik

Übersicht. Informatik 2 Teil 3 Anwendungsbeispiel für objektorientierte Programmierung

Klausur zur Einführung in die objektorientierte Programmierung mit Java

Softwarequalitätssicherung

Einführung in die Informatik: Programmierung und Software-Entwicklung, WS 14/15. Kapitel 11. Fehler und Ausnahmen 1

Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung

Innere Klassen in Java

Software Tests. Florian Ehmke. 21. Januar / 40

Einführung in die Programmierung mit Java

Einführung in Java. PING e.v. Weiterbildung Andreas Rossbacher 24. März 2005

Einführung in die Programmierung mit Java

Grenzwertanalyse. Domain-Testing. Ronny Schwierzinski, Bernd Rabe, Anna Bartwicki

Ein Testprozess für Modellbasiertes Testen

Übungen zur Vorlesung Einführung in die Informatik Wintersemester 2010/11

Programmieren was ist das genau?

Aufgabenblatt Nr. 5 Generizität und TicTacToe

Interaktionen zwischen Objekten durch Senden von Nachrichten und Reagieren auf empfangene Nachrichten

Unit Testing mit JUnit. Dr. Andreas Schroeder

Programmieren I. Die Programmiersprache Java. Institut für Angewandte Informatik

Vorlesung Objektorientierte Programmierung Probeklausur

Java: Vererbung. Teil 3: super()

2.2 Prozesse in Java

Software Engineering I

Gliederung. Tutorium zur Vorlesung. Gliederung. Gliederung. 1. Gliederung der Informatik. 1. Gliederung der Informatik. 1. Gliederung der Informatik

Überblick. Einleitung. Unit-Tests. JUnit. HelloWorld Beispiel. Praktische Beispiele. Referenzen

PIWIN I. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler I. Vorlesung 3 SWS WS 2007/2008

Testen mit JUnit. Martin Wirsing. in Zusammenarbeit mit Matthias Hölzl, Nora Koch 05/03

Einführung in die objektorientierte Programmierung mit Java. Klausur am 19. Oktober 2005

Informatik Sommercamp 2012

Modulare Programmierung und Bibliotheken

Lösungsvorschläge. zu den Aufgaben im Kapitel 4

Transkript:

Qualitätssicherung von Software Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FIRST

2. Testverfahren 5.11.2004 Folie 2 Bücher zum Testen Myers, Glenford J.: The Art of Software Testing. Wiley & Sons (1979) (auch in deutsch erhältlich: Methodisches Testen von Programmen ; Neuauflage in Vorbereitung) Andreas Spillner, Tilo Linz: Basiswissen Softwaretest. DPUNKT Verlag (2003) (für ASQF Zertifizierung) Bart Broekman, Edwin Notenboom: TestingEmbeddedSoftware, Addison-Wesley (2003) (DC) Harry Sneed, Mario Winter: Testen objektorientierter Software. Hanser (2002) Edward Kit: Software Testing in the Real World Improving the process. Addison-Wesley (1995) Dorothy Graham, Mark Fewster: Software Test Automation - Effective Use of Test Execution Tools. Addison-Wesley (2000) Cem Kaner, Jack Falk, Hung Q. Nguyen: Testing Computer Software. Wiley (2 ed. 1999) Marnie L. Hutcheson: Software Testing Fundamentals - Methods and Metrics. Wiley (2003) Georg E. Thaller: Software-Test. Heise (2002)

2. Testverfahren 5.11.2004 Folie 3 Kapitel 2. Testverfahren 2.1 Testen im SW-Lebenszyklus 2.2 funktionsorientierter Test! Modul- oder Komponententest! Integrations- und Systemtests 2.3 strukturelle Tests, Überdeckungsmaße 2.4 Test spezieller Systemklassen! Test objektorientierter Software! Test graphischer Oberflächen! Test eingebetteter Realzeitsysteme 2.5 automatische Testfallgenerierung 2.6 Testmanagement und -administration

2.2 Funktionstest 5.11.2004 Folie 4 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

2.2 Funktionstest 5.11.2004 Folie 5 Ziele des Komponententests Aufdeckung von Fehlern im Modul " falsche Berechnungen " fehlende Programmpfade " Sonderfallbehandlung " unzulässige Ein- und Ausgabewerte " Robustheit gegenüber falscher Benutzung " sinnvolle Fehlermeldungen bzw. Ausnahmebehandlung nichtfunktionale Gesichtspunkte sind sekundär " Effizienz, Platz- und Zeitverbrauch " Spezifikation und Dokumentation " Wartbarkeit, Änderbarkeit,

2.2 Funktionstest 5.11.2004 Folie 6 Vorgehensweise 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 in Testsuiten

2.2 Funktionstest 5.11.2004 Folie 7 extreme Programming 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! " Tests während Implementierung immer verfügbar " Konzentration auf Interface statt Implementierung " durch Nachdenken über Testfälle Design-Fehler finden

2.2 Funktionstest 5.11.2004 Folie 8 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 IMathTestNoJUnit { /** 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

2.2 Funktionstest 5.11.2004 Folie 9 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?

2.2 Funktionstest 5.11.2004 Folie 10 JUnit (vgl. Übung!) 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!

2.2 Funktionstest 5.11.2004 Folie 11 JUnit (Forts.) 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)

2.2 Funktionstest 5.11.2004 Folie 12 Komponententest-Entwurf sehr entwicklungsnahe Testarbeit, oftmals direkt am ausführbaren Code " Problematik der Spezifikation (Wozu eine Spezifikation, wenn der Code selbst vorliegt?) fließender Übergang zum Debugging; oft von den Entwicklern selbst durchgeführt " Problematik der Zielsetzung (Fehler finden oder Ablauffähigkeit demonstrieren?) " Problematik des Hintergrundwissens aus der Entwicklung (für den Testentwurf oft notwendig, aber stillschweigende Annahmen behindern die Objektivität bzw. Abdeckung)

2.2 Funktionstest 5.11.2004 Folie 13 Ein klassisches Beispiel (Myers) Funktion mit drei int-eingabewerten (x,y,z), die als Längen von Dreiecksseiten interpretiert werden Berechnet, ob das Dreieck gleichseitig, gleichschenklig oder ungleichseitig ist Schreiben Sie für diese Funktion Testfälle auf! (jetzt!)

2.2 Funktionstest 5.11.2004 Folie 14 Auswertung nach Punkten (1) 1. Haben Sie einen Testfall für ein zulässiges gleichseitiges Dreieck? 2. Haben Sie einen Testfall für ein zulässiges gleichschenkliges Dreieck? (Ein Testfall mit 2,2,4 zählt nicht.) 3. Haben Sie einen Testfall für ein zulässiges ungleichseitiges Dreieck? (Beachten Sie, dass Testfälle mit 1,2,3 und 2,5,10 keine Ja-Antwort garantieren, da kein Dreieck mit solchen Seiten existiert.) 4. Haben Sie wenigstens drei Testfälle für zulässige, gleichschenklige Dreiecke, wobei Sie alle drei Permutationen der beiden gleichen Seiten berücksichtigt haben? (z.b. 3,3,4; 3,4,3; 4,3,3)

2.2 Funktionstest 5.11.2004 Folie 15 Auswertung nach Punkten (2) 5. Haben Sie einen Testfall, bei dem eine Seite gleich Null ist? 6. Haben Sie einen Testfall, bei dem eine Seite einen negativen Wert hat? 7. Haben Sie einen Testfall mit 3 ganzzahligen Werten, in dem die Summe zweier Zahlen gleich der dritten ist? (D.h., wenn das Programm 1,2,3 als ungleichseitiges Dreieck akzeptiert, so enthält es einen Fehler.) 8. Haben Sie wenigstens drei Testfälle für Punkt 7, wobei Sie alle drei Permutationen für die Länge jeweils einer Seite als Summe der beiden anderen Seiten berücksichtigt haben? (z.b. 1,2,3; 1,3,2; 3,1,2.) 9. Haben Sie einen Testfall mit drei ganzzahligen Werten größer Null, bei dem die Summe aus zwei Zahlen kleiner als die dritte ist? (z.b. 1,2,4 oder 12,15,30)

2.2 Funktionstest 5.11.2004 Folie 16 Auswertung nach Punkten (3) 10. Haben Sie wenigstens drei Testfälle für Punkt 9, wobei Sie alle drei Permutationen berücksichtigt haben? (z.b. 1,2,4; 1,4,2; 4,1,2.) 11. Haben Sie einen Testfall, in dem alle drei Seiten gleich Null sind (d.h. 0,0,0)? 12. Haben Sie wenigstens einen Testfall mit nichtganzzahligen Werten? 13. Haben Sie wenigstens einen Testfall, in dem Sie eine falsche Anzahl von Werten angeben (z.b. zwei statt drei ganzzahlige Werte)? 14. Haben Sie zusätzlich zu jedem Eingangswert in allen Testfällen die erwarteten Ausgabewerte angegeben?

2.2 Funktionstest 5.11.2004 Folie 17 Zusatzpunkte 15. Test mit maximalen Werten 16. Test auf Zahlbereichs-Überlaufbehandlung 17. Test mit unzulässigen Eingabezeichenfolgen

2.2 Funktionstest 5.11.2004 Folie 18 Reflexion Durchschnittswerte erfahrener Programmierer: 7-8 Diese Übung sollte zeigen, dass das Testen auch eines solch trivialen Programms keine leichte Aufgabe ist. Und wenn das wahr ist, betrachten Sie die Schwierigkeit, ein Flugleitsystem mit 100.000 Befehlen, einen Compiler oder auch nur ein gängiges Gehaltsabrechnungsprogramm zu testen. (1979) Heute: 1-10 MLoC

2.2 Funktionstest 5.11.2004 Folie 19 Pause!

2.2 Funktionstest 5.11.2004 Folie 20 Testentwurf im Komponententest Aus Komplexitätsgründen ist es nicht möglich, alle Eingabewerte(-folgen) zu testen Problem: Welche Untermenge aller denkbaren Testfälle bietet die größte Wahrscheinlichkeit, möglichst viele Fehler zu finden? #Techniken zur Testdaten- und Testfallbestimmung Äquivalenzklassenbildung " Auswahl repräsentativer Daten Grenzwertanalyse " Wertebereiche und Bereichsgrenzen Entscheidungstabellen und Klassifikationsbäume

2.2 Funktionstest 5.11.2004 Folie 21 Äquivalenzklassenbildung 1. Schritt: Partitionierung des Eingabedatenraumes in eine endliche Zahl von Äquivalenzklassen (bezüglich des vermuteten Ausfallverhaltens) " im Beispiel: drei gleiche Eingaben größer Null 2. Schritt: Auswahl der Testfälle anhand je eines Repräsentanten der Äquivalenzklasse " im Beispiel: (2,2,2)

2.2 Funktionstest 5.11.2004 Folie 22 Vorgehensweise zur Äquivalenzklassenbildung Betrachten der Definitionsbereiche für Ein-/Ausgabewerte Für jeden Wert ergeben sich gültige und ungültige Klassen " Wertebereiche, Aufzählungen: enthalten oder nicht enthalten " Eingabewerte, die (möglicherweise) unterschiedlich verarbeitet werden: für jeden Wert eine gültige und insgesamt eine ungültige Klasse " Ausgaben, die auf verschiedene Weise berechnet werden: je eine Klasse, die auf diese Ausgabe führt " Eingabebedingungen, die vorausgesetzt werden: je eine gültige und eine ungültige Klasse Aufspaltung einer Klasse in kleinere Klassen, falls Grund zur Annahme besteht, dass nicht alle Elemente gleich behandelt werden Tabellierung der zu jedem Parameter gehörigen Klassen

2.2 Funktionstest 5.11.2004 Folie 23 Vorgehensweise zur Testfallauswahl Äq1 Äq2 Äq3 Par1 Wert1.1 Wert1.2 Par2 Wert2.1 ParN Vollständig: Kartesisches Produkt der Klassen " meist nicht praktikabel Heuristisch: Auswahl gemäß folgender Strategie " Bildung von Testfällen, die möglichst viele noch nicht behandelte gültige Klassen abdecken " Bildung von Testfällen, die genau eine ungültige Klasse abdecken " Paarweise Kombination von Repräsentanten im Beispiel: (2,2,3) und (-7,1,2), (5, a,2)