systematisches testen der funktionalität von softwaresystemen · identifikation von...

Systematisches Testen der Funktionalität von Softwaresystemen

17. Juni 2015

Taentzer Softwarequalität 2015 182

Überblick Semantische Qualität von Software Teststrategien und –prinzipien

Testgetriebene Softwareentwicklung Welche Arten von Tests sind möglich?

Wann haben wir genug getestet? Codeüberdeckung Datenüberdeckung

Was tun, wenn die Daten fehlen? Mock-Objekte benutzen


Semantische Qualität

Die semantische Qualität von Software bezieht sich auf die Erfüllung der Anforderungsspezifikation: Erfüllung der funktionalen Anforderungen:

Funktionalität: Korrektheit, Vollständigkeit, Sicherheit, Fehlertoleranz

Erfüllung der folgenden nichtfunktionalen Anforderungen: Effizienz: Wirtschaftlichkeit, Zeitverhalten,

Verbrauchsverhalten


Nachweismöglichkeiten für semantische Qualität

Testen: exemplarische Programmausführungen, um Fehler (Defekte) zu finden

Zusicherungen: Konsistenzeigenschaften, die während der Programmausführung überprüft werden

Verifikation: Nachweis, dass alle Programm-ausführungen bestimmte Eigenschaften erfüllen

Welche Vor- und Nachteile haben diese verschiedenen Nachweis-möglichkeiten?

Repräsentative Tests Wir können im Allgemeinen nicht alle möglichen

Eingaben austesten. (Warum?) Deshalb wählen wir eine möglichst aussagekräftige

Menge von Testfällen aus. Ein Testfall ist repräsentativ, wenn er

eine neue Kombination von Eingabedatenkategorien prüft (in Blackbox- und Whitebox-Tests) oder

einen neuen Pfad im Programm durchläuft (nur in Whitebox-Tests).

Testziel: Alle möglichen Kombinationen von Eingabedatenkategorien

und alle Pfade des Programms sind getestet.


Identifikation von repräsentativen Testfällen (datengetrieben)

Zum datengetriebenen Testen einer funktionalen Einheit (z.B. Methode) hat sich das folgende Verfahren aus [OB88] bewährt:1. Erstelle ein Modell der Eingabedatenstrukturen:

Welche Datenkategorien gibt es für die Parameter? Welche Objekte der Umgebung müssen berücksichtigt werden?

2. Zerlege den Datenraum jeder Kategorie in Wahlmöglichkeiten3. Wie viele Kombinationen von Wahlmöglichkeiten gibt es?4. Welche Kombinationen sind möglich? Welche Abhängigkeiten gibt

es zwischen den identifizierten Wahlmöglichkeiten?5. Für jede mögliche Kombination von Wahlmöglichkeiten werden

passende Werte gewählt und ein Testfall geschrieben. Dieser enthält auch den Erwartungswert.


Beispiel für datengetriebene Tests


[OB88]



[OB88]

Mögliche Testläufe:



[OB88]

Kategorien und Wahlmöglichkeiten:



[OB88]

Eine Kombination von Wahlmöglichkeiten:

Ist diese Kombination möglich?



[OB88]

Wahlmöglichkeiten mit Abhängigkeiten:



[OB88]

Wahlmöglichkeitenmit Abhängigkeiten:



[OB88]

Auszeichnung von Wahlmöglichkeiten, die Fehler produzieren:



[OB88]

Auszeichnung vonWahlmöglichkeiten, die Fehler produzieren:

Diese werden nicht in Kombination mitanderen geprüft.

[single] identifiziertTestfälle, die auchnicht in Kombination geprüft werden müssen.



[OB88]

Ein konkreter Testfallfür die angegebene Kombination:

Ein Testfall pro zu prüfender Kombination

Skaliert diese Testmethode?

Einsatz in der testgetriebenen Entwicklung

Vorgehensweise: beschreibe wesentliche Testfälle schon mit den

Anforderungen folge dem vorgestellten Verfahren zur Identifikation von

repräsentativen Testfällen programmiere alle repräsentativen Testfälle führe die Testfälle aus: Fehler, da die Funktionalität noch

fehlt implementiere die Funktionalität führe die Testfälle aus: Code solange ändern, bis alle Tests

durchlaufen führe Refactorings durch



Mock-Objekte Was tun, wenn bestimmte Ressourcen (Komponenten)

noch nicht zum Testen zur Verfügung stehen? Beispiele: Datenbanken, Dateien, Server, Softwarekomponenten

Was tun, wenn eine Methode schwer testbar ist, weil Eingabeparameter nur sehr umständlich, eingeschränkt oder gar nicht erstellbar sind? Beispiele: Uhrzeit, GUI, Netzwerkfehler

Mock-Objekte: Attrappen, die echte Objekte simulieren Sie implementieren dieselben Schnittstellen wie die „echten“

Objekte. Sie unterstützen den Komponententest. (Warum?)

weitere Informationen: www.mockobjects.com


Beispiel: Mock-Objekte (manuell)<<interface>>

Course

getNextParticipant()

MockCourse


Lecture


public Person getNextParticipant() {//...Person p1 = new Person(„Meier“);//... return p1; }

public PersongetNextParticipant() {

return getManagement().getNextParticipant();}

Vorlesungsverzeichnis

VerzeichnisTest

Beispiel: Mock-Objekte mit Mockitoimport static org.mockito.Mockito.*; //…

@Test public void firstCourseTest(){ //arrange Course c=mock(MockCourse.class); when(c.getNextParticipant()).thenReturn(

new Person(“Maier”));//act String result=c.getNextParticipant(); //assert assertEquals(“Meier", result.toString()); }



Werkzeuge für das Testen mit Mock-Objekten

Wie wird getestet? Unit-Testing mit Mock-Objekten Mock-Objekt erzeugen Das erwartete Verhalten aufnehmen Mock-Objekt auf Abspielen des Verhaltens schalten

Was kann getestet werden? Aufruf von Methoden (auch die Anzahl und Reihenfolge) Rückgabewerte Werfen von Exceptions Verhalten zwischen mehreren Mock-Objekten

Werkzeuge für Java: EasyMock: http://www.easymock.org Mockito: http://code.google.com/p/mockito


Zusammenfassung

Semantische Qualitätsprüfungen: Testen, Zusicherungen, Verifikation

Testen ist eine analytische Qualitätssicherungsmaßnahme. Testen hilft, Fehler zu finden. Es kann nicht die Abwesenheit

von Fehlern zeigen. Zentrale Frage: Wann haben wir genug getestet? Repräsentative Testfälle

decken die möglichen Eingabewerte optimal ab und testen alle möglichen Programmabläufe (in Whitebox-Tests).

Mock-Objekte: falls die echten Daten für das Testen noch fehlen

Literatur[Mye95] Glenford J. Myers: Methodisches Testen von Programmen, Oldenbourg Verlag, 1995[Lin05] Johannes Link u. a.: Softwaretests mit JUnit. Techniken der testgetriebenen Entwicklung. 2. Auflage. dpunkt, 2005[OB88] T. Ostrand, M. Balcer: The category-partition method forspecifying and generating functional tests, Communication of theACM, 1988 www.cc.gatech.edu/~harrold/6340/cs6340_fall2009/Readings/ostrandCategoryPartition88.pdf


systematisches testen der funktionalität von softwaresystemen · identifikation von...

Documents