+ All Categories
Home > Documents > Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin...

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

Date post: 05-Apr-2015
Category:
Upload: wilda-helms
View: 106 times
Download: 0 times
Share this document with a friend
27
Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 18.4.2013: Modultest
Transcript
Page 1: Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 18.4.2013: Modultest.

Qualitätssicherung von Software (SWQS)

Prof. Dr. Holger Schlingloff

Humboldt-Universität zu Berlinund

Fraunhofer FOKUS

18.4.2013: Modultest

Page 2: Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und 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...

Page 3: Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 18.4.2013: Modultest.

Folie 3H. Schlingloff, Software-Qualitätssicherung

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

Page 4: Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 18.4.2013: Modultest.

Folie 4H. Schlingloff, Software-Qualitätssicherung

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%

Page 5: Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 18.4.2013: Modultest.

Folie 5H. Schlingloff, Software-Qualitätssicherung

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

Page 6: Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 18.4.2013: Modultest.

Folie 6H. Schlingloff, Software-Qualitätssicherung

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)

Page 7: Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 18.4.2013: Modultest.

Folie 7H. Schlingloff, Software-Qualitätssicherung

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

Page 8: Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 18.4.2013: Modultest.

Folie 8H. Schlingloff, Software-Qualitätssicherung

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, ...

Page 9: Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 18.4.2013: Modultest.

Folie 9H. Schlingloff, Software-Qualitätssicherung

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

Page 10: Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 18.4.2013: Modultest.

Folie 10H. Schlingloff, Software-Qualitätssicherung

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

Page 11: Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 18.4.2013: Modultest.

Folie 11H. Schlingloff, Software-Qualitätssicherung

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, …

Page 12: Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 18.4.2013: Modultest.

Folie 12H. Schlingloff, Software-Qualitätssicherung

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

Page 13: Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 18.4.2013: Modultest.

Folie 13H. Schlingloff, Software-Qualitätssicherung

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

Page 14: Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 18.4.2013: Modultest.

Folie 14H. Schlingloff, Software-Qualitätssicherung

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?

Page 15: Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 18.4.2013: Modultest.

Folie 15H. Schlingloff, Software-Qualitätssicherung

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

Page 16: Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 18.4.2013: Modultest.

Folie 16H. Schlingloff, Software-Qualitätssicherung

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)

Page 17: Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 18.4.2013: Modultest.

Folie 17H. Schlingloff, Software-Qualitätssicherung

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)

Page 18: Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 18.4.2013: Modultest.

Folie 18H. Schlingloff, Software-Qualitätssicherung

Page 19: Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 18.4.2013: Modultest.

Folie 19H. Schlingloff, Software-Qualitätssicherung

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]

Page 20: Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 18.4.2013: Modultest.

Folie 20H. Schlingloff, Software-Qualitätssicherung

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

Page 21: Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 18.4.2013: Modultest.

Folie 21H. Schlingloff, Software-Qualitätssicherung

Ä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

Page 22: Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 18.4.2013: Modultest.

Folie 22H. Schlingloff, Software-Qualitätssicherung

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

Page 23: Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 18.4.2013: Modultest.

Folie 23H. Schlingloff, Software-Qualitätssicherung

Kombination von Parameterwerten

Page 24: Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 18.4.2013: Modultest.

Folie 24H. Schlingloff, Software-Qualitätssicherung

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…

ParN

Page 25: Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 18.4.2013: Modultest.

Folie 25H. Schlingloff, Software-Qualitätssicherung

Ü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

Page 26: Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 18.4.2013: Modultest.

Folie 26H. Schlingloff, Software-Qualitätssicherung

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

Page 27: Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 18.4.2013: Modultest.

Folie 27H. Schlingloff, Software-Qualitätssicherung

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


Recommended