Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin...

transcript

Qualitätssicherung von Software (SWQS)

Prof. Dr. Holger Schlingloff

Humboldt-Universität zu Berlinund

Fraunhofer FOKUS

18.4.2013: Modultest

Folie 2H. Schlingloff, Software-Qualitätssicherung

Fragen zur Wiederholung

• Unterschied blackbox / whitebox Test?

• Was ist eine Testsuite?

• Notationsmöglichkeiten für Testfälle?

• Was vesteht man unter einem Testorakel?

• Was sind Testziele?

• Vor- und Nachteile von “test your own program”?

Nachtrag: www.testingfaqs.org scheint nicht mehr zu existieren...

Wo stehen wir?

Kapitel 2. Softwaretest

2.1 Testen im SW-Lebenszyklus2.2 Funktionale Tests, Modultests,

Testfallauswahl2.3 Strukturelle Tests,

Integrationstests2.4 Modellbasierte Tests

Kapitel 1: Einleitung, Begriffe, Software-Qualitätskriterien

Software Engineering Fakten

• Typische Verteilung der Entwicklungskosten: 10% Anforderungen, 10% Architektur, 20% Entwurf, 15% Implementierung, 45% Integration und Test

• Siemens: 7% der Entwicklungsaktivität ist Kodierung

• Qualitätssicherung beansprucht 30-80% der gesamten Entwicklungskosten

• Unit-Testen benötigt 40-70% des gesamtem Implementierungsaufwandes

• In sicherheitskritischen Systemen bis zu 90%

Specification-based versus Code-based

• Test case derivation source: specification or code?• Specification-based testing checks whether the

specified behaviour is implemented; it cannot find unspecified program behaviours (e.g. viruses)

• Program-code-based testing checks whether the implemented behaviour is correct (with respect to the specification); it cannot find unimplemented requirements (e.g. missing features)

Specification Program

Test Suite

Black-box versus White-Box

• White-Box: Structure is openly accessible and visible to the tester; e.g. reading and writing of program variables during test execution

• Black-Box: Internals are hidden (e.g. for copyright reasons); access only through documented external interfaces

• Grey-Box: Some internal details are revealed for testing purposes (e.g. special testing monitors)

Functional versus Structural Testing

•Focus on “functional”: performed function, i.e. actions or

activities of the SUT, “what” (external view)- e.g. relation between input and output values

“structural”: designed structure, i.e. components or implementation, “how” (internal view)- e.g. data and data types or algorithmic idea

•Often used synonymously: functional test – black-box-test – specification-

based test structural test – white-box-test – code-based test

Codebasierter Test: Modultest

weitgehend synonym: Modultest, Unit-Test, Komponententest

• Oftmals mit „dem Test“ gleichgesetzt 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)

• Oftmals die selbe Entwicklungsumgebung wie das SUT Compiler, Linker, IDE, ...

Modultest: Vorgehensweise

• Wer? Theorie: Programmierer ungleich Tester Praxis: Unit-test durch die Entwickler

• Wann? Theorie: Parallel zur Implementierung Praxis: Nach Fertigstellung des Moduls

- “Teste es bevor jemand anderes es sieht”

eXtreme programming: Testfälle vor der Implementierung- Testfälle sind während der Implementierung verfügbar

- Designfehler werden erkannt bevor überhaupt mit der Implementierung begonnen wird

Methodik des Modultests

• Jeder einzelne Baustein wird unabhängig von den anderen getestetVorteile: keine externen Einflüsse oder Wechselwirkungen klare und einfache Fehlereingrenzung und –lokalisierung Bausteine dürfen auch verschachtelt sein, keine zusätzlichen

Probleme

• SUT wird mit Testumgebung zusammengebundenVorteile: SUT Umgebung (Variablen) kann durch Testprogramm leicht

beeinflusst werden Aufruf von SUT Funktionen mit entsprechenden Parametern Auswertung durch Vergleich von Variablenwerten

Ziele des Komponententests

• Aufdeckung von Fehlern im Modul falsche Berechnungen, falsche Ausgaben

- falsche Instuktionen, Schleifen, Grenzen, Pointerarithmetik, ...

fehlende Programmpfade- fehlende Fälle, insbesondere fehlende Sonderfallbehandlung- Reaktion auf unzulässige Eingabewerte, Ausnahmebehandlung- Robustheit gegenüber falscher Benutzung

Redundante Fälle und Berechnungen- sich überschneidende Fälle, toter Code, unnötige Ausgaben

sinnvolle Fehlermeldungen bzw. Ausnahmebehandlung- falsche oder unzutreffende (Fehler-)meldungen, fehlende Meldungen

timing und Synchronisationsprobleme (schwierig!)

• nichtfunktionale Gesichtspunkte sind sekundär Effizienz, Platz- und Zeitverbrauch Spezifikation und Dokumentation Wartbarkeit, Änderbarkeit, …

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

Ein Beispiel

Beispiel: Yoonsik Cheon, University of Texas at El Paso, www.cs.utep.edu/~cheon/cs3331/notes/unit-testing.ppt

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)); }}

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?

JUnit (vgl. Übung!)

• 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()); }}

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)

Modultest als “der Softwaretest”?

• Unit-Tests sind nahe an der Implementierung, dem “tatsächlichen Produkt” sehr flexibel durch vollständige Zugriffsmöglichkeit auf das SUT oft durch die Entwickler durchgeführt, diese kennen den Code und

können daher effizient Testfälle entwickeln hilfreich zum Debuggen auf Grund der schnellen Fehlerlokalisierung;

ebenso zur Demonstration der Lauffähigkeit des SUT

• Probleme mit Unit-Tests fehlende Redundanz, Rollentrennung Die Spezifikation ist oft nur von sekundärer Bedeutung (Wozu eine

Spezifikation, wenn der Code selbst vorliegt?) Problem der impliziten Annahmen: Hintergrundwissen aus der

Entwicklung ist für den Testentwurf oft notwendig, aber stillschweigende Annahmen behindern die Objektivität bzw. Abdeckung

als Korrektheitsnachweis nur bedingt geeignet (die trügerische Sicherheit des grünen Balkens)

Beispiel: Die TiM-Funktion

• 30+((m mod 2) xor (m div 8))-n*(n==2)

• if m==2 then 28else if m<7 and even(m) or m>7 and odd(m) then 30 else 31

• if m==2 then 28else if m in {4,6,9,11} then 30 else 31

• array TiM=[31,28,31,30,31,30,31,31,30,31,30,31]return TiM[month]

Testfallauswahl im Komponententest

• Aus Komplexitätsgründen ist es nicht möglich, alle Eingabewerte(-folgen) zu testen 32-bit integer 1010 values (Tag, Monat, Jahr) 31*12*700=260.000 Kombinationen

• 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

Äquivalenzklassenbildung

• 1. Schritt: Partitionierung desEingabedatenraumes in eine endliche Zahl von Äquivalenzklassen (bezüglich des vermuteten Ausfallverhaltens) im Triangle-Beispiel: Gleichseitiges Dreieck,

d.h. „drei gleiche Eingaben größer Null“ z.B. für Integer [-maxint,-1] [0] [1,3] [4, maxint] z.B. für Tag [1,28] [29] [30] [31] und Monat [1 3 5 7 8 10 12] [4 6 9

11] [2]

• 2. Schritt: Auswahl der Testfälle anhand je eines Repräsentanten der Äquivalenzklasse im Beispiel: {(2,2,2)} oder: {-17396,0,2,72586} oder {17,29,30,31} und {7, 9, 2}

• 3. Schritt: Kombination der Repräsentanten in Testfälle nur “sinnvolle” Kombinationen

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

Kombination von Parameterwerten

Vorgehensweise zur Testfallauswahl

• Vollständig: Kartesisches Produkt aller Klassen meist nicht praktikabel

• Paarweise: Vereinigung aller Pari x Parj

• 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 abdeckenBeispiel (Tag Monat):

{(1,1), (29,4), (30,2), (31,1), (0,0)}

Äq1 Äq2 Äq3…

Par1 Wert1.1 Wert1.2

Par2 Wert2.1…

Übung

• Welche Testfälle ergeben sich aus der Äquivalenzklassenmethode?

• Welche wichtigen Fälle sind nicht abgedeckt?

public final class IMath { /* * Returns an integer approximation * to the square root of x. */ public static int isqrt(int x) { /* precondition x>=0 */ int guess = 1; while (guess * guess < x) { guess++; } return guess; }}

Parameter: x (int)Klassen: [-minint, -1] [0] [1,maxint]Repräsentanten: -1, 0, 1

Diskussion Äquivalenzklassenmethode

• Pro systematisches Vorgehen Überschaubare Anzahl Testfälle gut geeignet für “kleine” Funktionen mit Vor- und

Nachbedingungen

• Contra Auswahl der Testfälle durch eine Heuristik Abhängigkeiten zwischen Parameterwerten werden nicht

berücksichtigt bei komplexen Parametern ergeben sich viele

Äquivalenzklassen

Verbesserungsmöglichkeiten

•Grenzwertanalyse Fehler häufig an der Rändern einer

Äquivalenzklasse Neue Klassen für den Grenzwert selbst

sowie die Werte direkt daneben

•Entscheidungstabellenmethoden Klassifikationsbaummethode, CTE

Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin...

Documents