Testen, Testmanagement, Unit-Tests - beim Fachbereich Informatik ...

Vorlesung „Software Engineering“ 

Kapitel 3 Testmanagement und JUnit 

Version 1.0 

© Prof. Dr. Frank Bühler · Software Engineering · h_da - Fachbereich Informatik 

3.1 Software-Entwicklungsumgebungen 

3.2 Prototyping 

3.3 Testmanagement 

3.4 Unit-Tests: JUnit, CppUnit 

h_da 

Ohne Werkzeuge kann kein Softwaresystem entwickelt werden! 

Und gute Test-Werkzeuge und –Verfahren sind ein integraler Bestandteil 

jedes erfolgreichen Projektes! 

Hochschule Darmstadt 

University of Applied Sciences

Kapitel 3.1 Software-Entwicklungsumgebungen 

Motivation 

Die Entwicklung von Software erfordert den Einsatz unterschiedlichster 

Werkzeuge. Je nach Anwendungstyp können wenige oder viele (> 10) 

Werkzeuge verwendet werden, z. B. 

- CASE-Werkzeuge (UML-Modelle) und Generatoren 

- IDE mit Editor, Compiler (Übersetzer) und Binder (Linker) 

- Debugger und Testwerkzeuge 

- Werkzeuge für Konfigurations- und Versionsmanagement 

- Werkzeuge für ER-Modellierung, DBMS, Data Dictionaries und Repositories 

- Spezielle Editoren: Grafikeditor (Bildbearbeitung), XML-Editor 

- Application Server (für verteilte Systeme) 





Begriff SEU 

Eine Software-Entwicklungsumgebung (SEU) legt fest, mit welchen Werkzeugen 

gearbeitet werden soll und wie diese zusammenspielen (sollen). 

Leider gibt es keine "ideale SEU", die für alle Projekte passt und manchmal 

erfolgt eine "Umnutzung" von Werkzeugen (z. B. bei methodenfremden 

Werkzeugen). 

Oft müssen auch spezielle Tools (z. B. "Bridges") im Rahmen eines Projektes 

entwickelt werden, um den Werkzeugeinsatz zu verbessern oder erst zu 

ermöglichen. Beispielsweise ist dies notwendig, wenn wichtige Informationen in 

einer Form vorliegen, die sonst nicht direkt genutzt werden kann. Ein weiterer 

wichtiger Grund kann die Verbesserung der Qualität einzelner Artefakte sein. 

Gute Werkzeuge helfen die Qualität der Software zu verbessern und gleichzeitig 

auch die Produktivität zu steigern. 





Vorgehen 

Am Anfang eines jeden Projektes steht die Auswahl/Festlegung der Plattform und 

der Programmiersprache(n). Idealerweise ergibt sich diese aus der Bewertung 

der Anforderungen. 

Oft werden aber schon aus "politischen Überlegungen" heraus, Festlegungen für 

Werkzeuge und SEUs getroffen. 

Werkzeuge, die eingesetzt werden sollen, müssen auch zu der Architektur des zu 

entwickelnden Systems und dem methodischen Vorgehen passen. 





Vorgehen 

Die Beschaffung zentraler Entwicklungswerkzeuge sollte möglichst früh im 

Projekt (-> RUP: “Inception Phase/Environment Workflow“) erfolgen, damit die 

Entwicklungsumgebung rasch bereitgestellt werden kann. 

Falls notwendig, werden einzelne Werkzeuge untersucht und im Rahmen eines 

PoC (Proof-of-Concept) bewertet. Dies ist insbesondere dann notwendig, wenn 

die Preise sehr hoch sind (z. B. für ETL-Werkzeuge [Extraction, Transformation 

and Load] oder Portal-Software) sowie wenn Abhängigkeiten zu existierenden 

Umgebungen/Plattformen/Tools geklärt werden müssen. 

Nicht vergessen werden sollte, eventuell notwendige Schulungen, die sich 

idealerweise an den Projekt-Konventionen/Vorgaben orientieren. 





Management von SEUs 

Die Konzeption, der Aufbau und Betrieb einer SEU für ein mittleres bis großes 

Projekt stellt oft selbst ein Teil-Projekt dar, mit all den Regeln (z. B. 

Teamaufgaben, Budget und Termine). 

Das SEU-Projekt beginnt (immer) am 1. Tag des Gesamtprojektes und sollte 

bereits eine Start-Infrastruktur (z. B. Dokumenten-Server) sowie einige Projekt- 

Regeln/Konventionen bereitstellen. 





Entwicklungsrepositories 

Sofern absehbar ist, dass im Verlauf des Projektes viele Dokumente und weitere 

Artefakte entstehen werden, ist der Einsatz eines Entwicklungsrepositories zu 

prüfen. 

Dieses stellt neben den eingestellten Dokumenten auch konsistente 

Querverweise zu den verschiedenen Projekt-Artifakten bereit. 

Des weiteren dient es als "Single Point of Control" für Management-Aufgaben 

(z. B. Überwachung des Projektfortschrittes, Qualitätskontrolle) 





Einsatz von Debugging-Werkzeugen 

Oft entstehen massive Projektprobleme beim Einsatz von "intelligenten" 

Generatoren. 

Das Problem besteht darin, dass durch umfangreiche Generierungen (z. B. bei 

Einsatz von SQL-Präprozessoren) nicht mehr der direkte Bezug zum Quelltext 

existiert bzw. nur schwer hergestellt werden kann und somit der Entwickler erst 

Erfahrungen bzgl. möglicher Fehlerquellen aufbauen muss. 

Test- und Debuggingwerkzeuge sollten daher sorgfältig in Bezug auf die 

eingesetzten Generatoren ausgewählt werden. 




Agenda 










Begriff 

Ein Software-Prototyp ist ein - mit wesentlich geringerem Aufwand als das 

geplante Produkt - hergestelltes System, das nicht alle Eigenschaften des 

Zielsystems besitzt aber zur Erprobung und Beurteilung einiger angestrebter 

Systemeigenschaften verwendet werden kann. 

Beispiel: Prototyp zur Entwicklung einer besonderen Oberfläche (GUI) 

- statischer Prototyp (Entwicklung einzelne Bildschirmmasken) 

- dynamischer Prototyp (Übergang zwischen Dialogen, evtl. Testdaten integriert) 





Klassifikation von Prototypen 

Explorative Entwicklung 

- Gemeinsame Definition der benötigten Systemfunktionen durch Endanwender 

und Software-Ingenieure 

- Diskussion von verschiedenen Lösungsideen 

- Entwicklung von Prototypen, um Funktionen (und deren Änderbarkeit) zu testen 

- Es wird geprüft, ob das System im gegebenen organisatorischem Umfeld 

realisierbar ist. Es wird daher in erster Linie die Problemanalyse und 

Systemspezifikation unterstützt. 





Werkzeugeinsatz 

- Für die Entwicklung von Prototyp-Systemen werden sog. Rapid Application 

Development (RAD)-Werkzeuge eingesetzt. 

- Diese sollen eine schnelle Realisierung ermöglichen 

Beispiel: Oberflächenprototyp 

- Entwicklung mit Visual Basic anstelle einer komplexen 

grafischen Bibliothek 

Es wird somit frühzeitig evaluiert, ob eine Benutzeroberfläche für die Zielgruppe 

einsetzbar ist. 






Evolutionäre Entwicklung 

- Systementwicklung in mehreren Stufen 

- Vorgehen erfolgt gemäss Priorisierung der (unstrittigen) Benutzeranforderungen 

- Jede Stufe realisiert und integriert weitere Anforderungen abnehmender 

Priorität und ist somit in das Gesamtprojekt stark integriert. Die Grenze 

zwischen Prototyp und Zielsystem verschwimmen. 






Experimentelle Entwicklung 

- Entwicklung eines schmalen Ausschnitts eines geplanten Systems als 

„Durchstich“ (z. B. substantieller vertikaler Prototyp durch alle Schichten) 

- Simulation/Untersuchung der Wechselwirkungen zwischen den 

Systemkomponenten und zentraler Schnittstellen (z. B. Kommunikation 

zwischen Mainframe und Unix-System) 

- Prüfung neuer Software (z. B. ETL-Werkzeug) 

Experimentelle Prototypen sind meist „Wegwerf-Prototyp“ und versuchen 

mögliche Projektrisiken möglichst früh (und nicht erst bei Entwicklung/Test) 

zu erkennen. 




Agenda 









Kapitel 3.3 Testmanagement 

Testen 

Das Testen von Software gehört zu den wichtigsten (und oft auch ungeliebten) 

Tätigkeiten bei der Softwareerstellung. 

Eine SEU sollte sowohl die Dokumentation und Bewertung der Testfälle als auch 

die Wiederholbarkeit (Regressionstests, Lasttest, Testfallautomatisierung) 

unterstützen. 





Überblick zu Testverfahren 

Dynamische Tests: Black-Box-Verfahren vs. White-Box-Verfahren 

Statische Tests: Code-Inspektion u. a. 

Verifikation : Nachweis der Korrektheit (mit formalen Methoden) 

Validierung : Überprüfung von Eigenschaften der Anwendung 

(-> wurde das richtige System entwickelt?) 

Debuggen : Fehlersuche 





Testprozess *) s. a. nachfolgende Folien 

Dynamisch 

- Planung 

- Entwurf 

- Review 

- Vorbereitung 

- Ausführung 

- Nachbereitung 

Statisch 

- Inspektion 





Testprozess Planung 

- Festlegung der Testobjekte und Testziele 

- Wie soll getestet werden (Richtlinien und Standards)? 

Einsatz welcher Testverfahren? 

- Kriterien zur Beendigung des Testens 

- Zeitplan (wann soll etwas getestet werden?) 

- Verantwortungsbereiche (Wer testet? Wer liefert was (z. B. Testdaten)?) 

- Testdokumentation / Testprotokoll 

- Testwerkzeuge, Testkonfiguration 





Testprozess Entwurf 

- Festlegung der Testfälle, Testablaufpläne 

- Eingabeverfahren und -formate der Testdaten 

- Ausgabeverfahren und -formate der Testergebnisse 

- Evaluierung der Testumgebung und Werkzeuge, wie soll/kann getestet werden? 





Testprozess Review 

Prüfung/Bewertung des geplanten Testverfahrens 

Review-Fragen, z. B. 

- Wurde beim Entwurf der Testfälle das jeweils richtige Testverfahren 

eingesetzt? 

- Sind ausreichend viele Testfällen definiert? 

- Was sind Voraussetzungen um erfolgreich zu testen? 





Code Coverage vs. Path Coverage 

100 % Code-Abdeckung: 

A && B 

!A && !B 

oder 

!A && B 

A && !B 

Linearer Aufwand 


y 

y 

Condition A 

n 

Condition B 

n 

100 % Pfad-Abdeckung 

A && B 

!A && !B 

und 

!A && B 

A && !B 

Exponentieller Aufwand 




Testprozess Vorbereitung 

- Vorbereitung der Systemkonfiguration, auf der getestet wird, 

Bereitstellung der Testobjekte und Generierung der Testdaten aus den 

Testfällen 

- Installation und Integration von Geräten, die Prozeßverhalten simulieren 

- Installation und Integration evtl. notwendiger Testwerkzeuge 





Testprozess Ausführung 

- Testobjekt wird mit den Testdaten zur Ausführung gebracht 

- Testergebnisse werden protokolliert, dokumentiert und verwaltet 

Beispiele 

- Testen von Schnittstellen (Black-Box) 

- Testen von Komponenten (White-Box) 

- Testen des Zusammenspiels von Komponenten 





Black-Box-Test 

• Test der Schnittstelle einer Klasse ohne Betrachtung der Interna 

Eigenschaften des Black-Box-Tests 

- dynamische Tests 

- Aufwand für Tests liegt im vertretbaren Rahmen 

Wichtige Fragestellungen 

- Funktioniert der Schnittstellenaufruf? 

- Werden die korrekten Ergebnisse erstellt? 

- Werden alle Methoden vom Programm benutzt? 

- Welche Wirkung hat eine Methode auf andere Objekte? 

Achtung: 

ausschließliche Betrachtung der Ausgabedaten 

nicht ausreichend, auch Zustandsänderungen 

und Seiteneffekte überprüfen! 


Eingabedaten 

Black-Box 

Klasse 

Methode 2 

Methode 3 

Aktueller 

Zustand 

Methode 1 

Ausgabedaten 

Testauswertung 




White-Box-Test 

� Test der Klasse mit Betrachtung der Interna 

� Test aller Methoden 

� Durchlauf aller möglichen Pfade (Testabdeckung) 

Eigenschaften des White-Box-Tests 

- dynamische Tests 

- großer Aufwand und hohe Komplexität 

Wichtige Fragestellungen 

- Welcher Testabdeckungsgrad soll erreicht werden? 

- Wie hoch ist der Testaufwand? 

- Können Tests automatisiert werden? 


Testabdeckungsgrade: 

C0 – Jede Anweisung wird min. 

einmal durchlaufen 

C1 – Jeder Zweig wird min. 

einmal durchlaufen. 

C2 – Jede Bedingung wird min. 

einmal verwendet. 

C3 – Jeder Zweig und jede 

Schleifengrenze wird 

min. einmal durchlaufen. 

C4 - ... 

Aufwand und Anzahl gefundener 

Fehler steigen 




Testprozess Nachbereitung 

� Analyse und Vergleich der Testergebnisse mit den erwarteten Ergebnissen 

� Beschreibung, Analyse und Dokumentation der Fehler 

� Weiterleitung der Fehler an die Fehlerstatistik 

� Suche nach Ursachen für festgestellte Fehler im Testobjekt 

� Erstellung eines Auftrags zur Fehlerbehebung 

� Fehlerbehebung 





Testprozess *) s. a. nachfolgende Folien 

Dynamisch 

- Planung 

- Entwurf 

- Review 

- Vorbereitung 

- Ausführung 

- Nachbereitung 

Statisch 

- Inspektion 





Testprozess Inspektion 

� Prüfung bzgl. korrekter Testausführung 

� Entwurfsinspektion („Dokumentenprüfung“), Dauer 1-2 Stunden 

- Entwerfer/Ersteller, Moderator, erfahrener Programmierer, 2-3 weitere 

Teilnehmer 

(z. B. Programmierer, Wartungspersonal) 

- Fallweiser Abgleich der Anforderungsdefinition mit Entwurf 

- Kritische Stellen werden mit dem Entwerfer/Ersteller diskutiert 

- Protokollierung der entdeckten Fehler und Schwachstellen 

- spätere Durchführung der Fehlerkorrekturen (nach Sitzung) 





Testprozess Inspektion (Beispiel für Abnahme-Workshop) – 1(2) 

Begrüßung � Moderator gibt Einführung über Ziele und Inhalt an die 

Teilnehmer des Workshops 

Vorgehen/Methodik � Zusammenfassung der Zielsetzung und 

Aufgabenstellung 

� Darstellung des Vorgehens bei Inspektion zur Erzielung 

der geforderten Ergebnisse 

� Erläuterung des Teams, das Dokument erstellt hat 

� Erklärung des Vorgehens für die Abnahme 

Ergebnisse 

(inhaltlich präzisiert) 


� Übersicht der Ergebnistypen 

� Erläuterung der Einzelergebnisse anhand geeigneter 

(visueller) Darstellungen 




Testprozess Inspektion (Beispiel für Abnahme-Workshop) – 2(2) 

Abgrenzung / 

Prämissen 


� Aufzeigen der wichtigsten Annahmen und ggfs. deren 

Konsequenzen 

� Darstellung von nicht berücksichtigten Aspekten 

� Aufzählung der Schnittstellen zu anderen 

Ergebnistypen und deren (Nicht-)Berücksichtigung 

Mängelfeststellung � Aufnahme von Mängeln und Feststellung der Schwere 

Ende des WS � Feststellung der Abnahme (ggfs. mit Auftrag die 

Mängeln nachzubessern) 

Weitere Aktivitäten � Statusverfolgung der Mängel und Anmerkungen 

� Ablage und Versionierung des Dokumentes 

(„Meilensteinverzeichnis“) nach erfolgter Korrektur 

ohne Mängelliste 




Testprozess Inspektion (Beispiel für Abnahme-Workshop) 

- Die Dokumentation der Anmerkungen und Mängel aus der Qualitäts- 

sicherung erfolgt in dem jeweiligen Ergebnisdokument in einer vorgegebenen 

Erfassungstabelle. 

- Dort wird auch die Priorisierung und Folgeaktivitäten (Maßnahmen, 

Verantwortliche, Terminierung) dokumentiert. 

- Aufbau der Erfassungstabelle 

Nr./Referenz, Datum, Mangel, Prio (hoch, mittel, niedrig), 

Verantwortlicher, Termin, Status (in Klärung, erledigt, abgelehnt) 






Codeinspektion („Softwareprüfung“), Dauer 1-2 Stunden 

- Programmierer des Produkts, Moderator, Testspezialist, Entwerfer 

- Verteilung der Programmliste sowie Entwurfsspezifikation an Sitzungsteilnehmer 

- Programmierer erläutert Programmlogik Schritt für Schritt 

- Kritische Fälle werden durchgespielt 

- Analyse des Codes anhand einer Checkliste der häufigsten Fehler 

- Protokollierung der Fehler aber keine Korrektur (nach Sitzung) 






Codeinspektion („Softwareprüfung“) - Checkliste 

- Variablenbenutzung 

z. B. korrekte Initialisierung, Indexgrenzen von Arrays, Verwendung von 

Pointern, Anzahl und Typ von Argumenten bei Unterprogrammen 

(Funktionen, Moduln, APIs) 

- Variablenvereinbarung 

z. B. Deklaration aller notwendigen Variablen, Bennenung von Variablen 

(Einhaltung der Namenskonventionen, ähnliche Variablennamen), 

Vereinbarung von globalen Variablen an richtiger Stelle 

- Berechnungen 

z. B. Über-/Unterlauf bei Zwischenergebnissen, Division durch Null, 

Prioritäten bei Operationen 







Welche Checks werden vom Compiler durchgeführt 

und welche können andersweitig automatisiert werden? 

Codeinspektion („Softwareprüfung“) - Checkliste 

- Vergleiche 

z. B. Verträglichkeit bei unterschiedlichen Datentypen, korrekte 

Verwendung von boolschen Ausdrücken 

- Programmablauf 

z. B. Schleifen, Erfüllung von Eingangsbedingungen, Berücksichtung 

aller Fälle 

- Schnittstellen 

z. B. Parameter, globale Variablen 

- Dateiein-/ausgabe 

z. B. Dateiende, Satzzugriff 

- Weitere Prüfungen 

z. B. Nicht verwendete Variablem, Warnmeldungen beim Compilieren 




Teststufen 

� Modultest 

� Integrationstest / Subsystemtest 

� Systemtest 

� Abnahmetest 

� Installationstest 

� Usability Test 

� Regressionstest 





Teststufen Modultest 

� Testen kleiner / elementarer Programmeinheiten 

� Module auf gleicher Ebene können gleichzeitig getestet werden 

� Simulation der Testumgebung z. B. durch Treiber oder weiterer Werkzeuge 





Teststufen Integrationstest / Subsystemtest 

� Montage von elementaren Testobjekten zu größeren Einheiten 

und Testen dieser Einheiten 

� Testet Schnittstellen und Zusammenspiel von Modulen 

� Vorgehensweisen beim Integrationstest („Teststrategie“): 

> inkrementell, top down, funktionsorientiert, ... 





Teststufen Systemtest 

� Testen des Systems als Ganzes im Hinblick auf verschiedene 

Qualitätsmerkmale: 

> Vollständigkeit 

> Leistung 

> Volumen 

> Stresstest / Lasttest 

> Sicherheit 

> Benutzerfreundlichkeit 

> Dokumentation 

> Kompatibilität 

> ... 





Teststufen Abnahmetest 

� Testen des Systems durch den Auftraggeber 

� im Idealfall sind bereits im Vertrag Abnahmekriterien festgelegt 

� Versuch, nachzuweisen, daß die Anforderungen nicht erfüllt sind 

� Protokolle der vom Auftragnehmer durchgeführten Tests sind hilfreich 





Teststufen Installationstest 

� Wird nach der Installation des Systems auf der Zielplattform durchgeführt 

� Ziel: Aufdecken von Installationsfehlern 

> Installation des vollständigen Systems 

> Vollständigkeit der benötigten Hardware 

> Verbindung zu anderen Programmen 

> Einstellung der Parameter, der Systemoptionen 

> ... 





Teststufen Usability Test 

� Prüfen, ob Benutzung des Systems durch Anwender effizient erfolgt 

(Benutzerfreundlichkeit und Akzeptanz) 

� Durchführung von typischen Aufgabenszenarien durch Benutzer 

� Aufzeichnung der Reaktionen 

==> Optimierung des SW-Systems 

Durchführung (6 Schritte) 






1. Produkt Analyse 

Zuerst wird die zu testende Software zur Vorbereitung analysiert und auf evtl. 

Usability Schwachstellen hin überprüft. 

2. Pre-Test & Vorbereitung 

Während der Vorbereitungsphase werden die Ziele des Usability Testes 

gemeinsam mit dem Auftraggeber vereinbart. Die Verhaltensbeobachtungssoftware 

sollte für jeden Usability Test individuell auf die Bedürfnisse und 

Ziele des Testes konfiguriert werden. 






3. Durchführung des Tests (Beispiel) 

Für die Zeitdauer der Testdurchführung befindet sich der Anwender alleine und 

ungestört im Testraum. Dieser ist vom Beobachtungsraum durch einen 

sogenannten "one-way-mirror" getrennt. Der Anwender sieht so die 

Beobachter während des Testes nicht und kann so ungestört die 

vorgegebenen Aufgabenstellungen durcharbeiten. Der Anwender und der 

Testverantwortliche kommunizieren während der Testphase über Mikrophon. 

Der Anwender führt eine Aufgabe nach der anderen aus. Während dieser Zeit 

wird er vom Testverantwortlichen, dem Protokollführer und anderen im 

Beobachtungsraum anwesenden Personen beobachtet. Der Anwender wird 

gebeten, während des Testes "laut zu denken" und seinen Emotionen so gut 

wie möglich freien Lauf zu lassen. 






4. Debriefing 

Unmittelbar nach dem Test wird der Anwender durch den Testverantwortlichen 

im Test Raum interviewt, um zusätzliche Kommentare oder Bemerkungen des 

Anwenders festzuhalten (-> Videoaufzeichnung). 

5. Test Analyse & Auswertung 

Nach Durchführung aller Tests, werden die Testdaten analysiert und 

ausgewertet. Auf Wunsch werden die Highlights des Tests in einem Highlight- 

Clip zusammengestellt. 

6. Erstellung des Test-Berichtes 

Alle Test-Protokolle werden nochmals überprüft, die Video Sequenzen 

nochmals abgespielt. Alle Testresultate werden in einem Testbericht, 

zusammengefasst und evtl. dem Kunden präsentiert. 






Heuristische Evaluation 

Eine heuristische Evaluation ist eine Inspektionsmethode, d.h. ohne 

Testpersonen. Usability-Kriterien werden für eine heuristische Evaluation 

angewendet. Sie wird von Usability-Experten durchgeführt, die eine Liste von 

bewährten Usability-Prinzipien anwenden. Wird ein SW-Produkt von 3-5 

erfahrenen Experten begutachtet, können bis 90% der Usability Probleme 

gefunden werden. 






Cognitive Walkthrough 

Ein Cognitive Walkthrough ist eine aufgabenorientierte Usability 

Inspektionsmethode, d.h. ohne Testpersonen. Der Usability-Experte erkundet die 

Funktionalitäten im Interesse eines imaginären Benutzeres. Dabei geht er davon 

aus, dass der Kunde das SW-System erkundet und den Weg des geringsten 

kognitiven Aufwands gehen wird. Der Usability Experte legt deshalb Wert auf 

gute Erlernbarkeit der Software und ermittelt für jede mögliche Aktion den 

voraussichtlichen kognitiven Aufwand. 





Teststufen Regressionstest 

� Einsatz bei der inkrementellen Softwareentwicklung und in der Wartungsphase 

� Änderungen an existierenden Klassen können korrektiv (Spezifikation verletzt), 

inkrementell (Spezifikation erweitert), adaptiv (Spezifikation geändert) oder 

optimierend (Spezifikation unverändert) sein. 

� In keinem Fall darf hierbei eine Regression auftreten, d.h., die geänderten 

Klassen müssen weiterhin (den unveränderten Teilen) der Spezifikation 

genügen. 

� Bei jeder neuen Softwareversion müssen die Original-Tests wiederholt werden, 

um sicherzustellen, daß Modifikationen das gewünschte Ergebnis bringen und 

keine unerwünschten Nebeneffekte aufgetreten sind. 





Teststufen Regressionstest 

Bei Regressionstest treten zwei grundlegende Probleme auf: 

� Änderungsanalyse (change impact analysis) 

zur Bestimmung der Regressionsmenge, d.h. der von einer Änderung 

möglicherweise betroffenen und somit neu zu testenden Teile des 

Anwendungssystems 

� Testfallauswahl (selective regression testing) 

die Bestimmung aller im Regressionstest erneut auszuführenden Testfälle. 

Dies ist notwendig, da aus Zeitgründen nach jeder Iteration nicht alle Tests 

erneut durchgeführt werden können. Eine sichere Testfallauswahl muss hierbei 

alle Testfälle berücksichtigen, deren Ausführung Fehler im modifizierten 

Anwendungssystem aufdecken können. 





QS-Kosten 

� ca. 50% der Entwicklungszeit (= 50% der Entwicklungskosten), 

alle QS-Maßnahmen: 30-90%, nur Test: 10-25%) 

� Der Aufwand für die Überarbeitung bereits erstellter Arbeitsschritte beträgt ca. 

30-40% der Entwicklungszeit. Diese Zeit unterteilt sich in etwa wie folgt: 

> 30-50%: Testfallermittlung 

> 20-40%: Testdaten- und Testprozedurenerstellung 

> 20-50%: Testdurchführung 

bzw. 

> Testvorbereitung ca. 60 - 80 % 

> Testdurchführung und Testauswertung ca. 20 - 40 % 





Anforderungen der ISO 9001 an die Qualitätssicherung (Auswahl) 

Der Lieferant muß ... 

� für Prüftätigkeiten Verfahrensanweisungen erstellen 

� ein Produkt, wie im QM-Plan / in Verfahrensanweisungen gefordert, prüfen 

� ein Produkt zurückhalten, bis 

� die geforderten Prüfungen abgeschlossen sind und 

� die Ergebnisse die Qualitätsanforderungen erfüllen sowie 

� die zugehörigen Daten und Dokumente verfügbar und genehmigt sind 

� Aufzeichnungen einführen, die für den Nachweis sorgen, dass das Produkt 

geprüft worden ist 

� Sofern das Produkt die Annahmekritierien nicht erfüllt, müssen die 

Verfahren für die Lenkung fehlerhafter Produkte angewendet werden 

(Quelle: DIN, EN, ISO /DIN EN ISO 9001 Aug. 94/) 




Agenda 









Kapitel 3.4 JUnit 

Überblick UNIT-Tests 

- Seitdem Extreme Programming (XP) und agile Methoden mehr Beachtung 

erhalten haben, ist die Durchführung von Tests (insbesondere Akzeptanz- und 

Unit-Tests) zu einer zentralen Tätigkeit geworden 

- Ein Test kann unterschiedliche Arten von Units umfassen (z. B. Methode, 

Klasse, Software-Paket, Sub-System) 

- Ein Test-Framework kann das Überprüfen der Units vereinfachen/ 

systematisieren und ermöglicht insbesondere die Automatisierung der Tests 

- Es exitieren Test-Frameworks für verschiedene Programmiersprachen, z. B. 

JUnit, cppUnit 

Grundprinzipien 

- Erst denken, dann coden. 

- Erst testen (!) dann coden. 

=> Test a little, write a little, test a little, write a little. 





Testgetriebene Softwareentwicklung – Test-First-Programmierung 

Kent Beck beschreibt diesen Ansatz mit zwei einfachen Regeln: 

- Schreibe nur dann neuen Code, wenn ein automatisierter Test fehlschlägt 

- Eliminiere Duplikation 

Dies bedeutet in der Praxis: 

1. Schreibe einen Test, der zunächst fehlschlagen sollte. Schreibe gerade 

so viel Code, dass der Test kompiliert. 

2. Schreibe gerade so viel Code, dass alle Tests – inklusive des neuen Tests – 

laufen. 

3. Eliminiere Duplikation und andere Code-Probleme. 

Dieser Zyklus wird auch unter dem Slogan „Test! Code! Refactor!“ zusammengefasst. 





Was ist JUnit? 

- Test-Framework zum Test von Java-Anwendungen 

(JUnit bietet Klassen an, um geschriebenen Java-Quelltext leicht zu prüfen) 

- JUnit verlangt während der Tests keine Benutzerinteraktion und ermöglicht so 

die Automatisierung der Tests 

- Bei der Nutzung von JUnit (und anderen Test-Frameworks) geht es um die 

Erstellung von leistungsfähigen Test-Treibern (zum Testen von Methoden 

[Design by Contract], von Klassen [CUT – Class under Test] und der Interaktion 

zwischen zwei oder mehreren Objekten) 

- Die Sprache zur Testspezifikation ist die gleiche wie bei der Programmierung 

der Anwendung, der Testcode wird aber vom Anwendungscode strikt getrennt 





TestCase und TestSuite 

Durch das gemeinsame Interface Test ist es möglich, Tests von TestSuiten und 

von TestCases durchzuführen. Hierdurch ist mit einem einzelnem Aufruf das 

Testen von ganzen Paketen möglich. 





Testablauf 

- Jeder Test wird grundsätzlich gekapselt: 

+ vor jedem Test werden die Werte mit setUp() initialisiert 

+ mit runTest() der Test durchgeführt und 

+ mit tearDown() aufgeräumt. 

(jeder Aufruf der drei Routinen ist durch try-catch-Blöcke gekapselt) 

Assert 


TestCase TestSuite 

EigenerTest 

 

Test 

* 




JUnit Assertions 

assertTrue(boolean condition) 

assertFalse(boolean condition) 

assertEquals(Object expected, Object actual) 

assertSame(Object expected, Object actual) 

assertNotSame(Object expected, Object actual) 

assertEquals(float expected, float actual, float tolerance) 

assertNull(Object o) 

assertNotNull(Object o) 

fail(String message) 





JUnit Beispiel 

package fbi.Junit; 

public class Student { 

private String name; 

private int studentID; 

} 

public Student(String first, 

String last, int id){ 

this.name = last; 

this.studentID = id; 

} 

public String getName(){ 

return this.name; 

} 

public int getID(){ 

return this.studentID; 

} 


package fbi.Junit; 

import junit.framework.TestCase; 

public class TestStudent extends TestCase{ 

private Student student_1; 

protected void setUp(){ 

student_1 = new Student("Peter", "Parker", 

10500015); 

} 

} 

public void testID(){ 

assertEquals(student_1.getID(),10500015); 

} 

public void testNames(){ 

assertSame(student_1.getName(), "Parker"); 

} 




JUnit Testlauf 

Aufruf mittels “TestRunner” (textuelle oder grafische Schnittstelle) 

-> java junit.swingui.TestRunner fbi.Junit.TestStudent 

fbi.Junit.TestStudent 

fbi.Junit.TestStudent 


JUnit Report 



Kapitel 3.4 CppUnit 

CppUnit (http://sourceforge.net/projects/cppunit) 

CppUnit ist ein in Anlehnung an JUnit entwickeltes Werkzeug zur 

Entwicklung von automatisierten Unit-Tests für C++ im Rahmen eines 

testgetriebenen Entwicklungsansatzes (test driven development, test first 

development). 





Unit-Tests 

Ein Unit-Test ist eine Methode in einer Testklasse und bezieht sich in der 

Regel immer auf eine korrespondierende Klasse, deren Verhalten getestet 

wird. 

- Ein solcher Test interagiert dabei mit einer Instanz der zu testenden Klasse 

über deren öffentliche (public) Methoden. 

- Gegebenenfalls nimmt der Test Instanzen anderer Klassen zu Hilfe. Diese 

müssen bevor der Test beginnt in einer Testvorrichtung (test fixture) 

bereitgestellt werden. 

- Anschließend versichert (assert) sich der Test, ob das Verhalten richtig war. Es 

gibt hier nur zwei Möglichkeiten: ja oder nein. Dementsprechend war der Test 

erfolgreich oder schlug fehl. 

- Jeder Test ist für sich abgeschlossen und untersucht einen bestimmten 

Teilaspekt der zu testenden Klasse. Unit-Tests müssen so konstruiert sein, 

dass sie in einer beliebigen Reihenfolge ausgeführt werden können. 





Beispiel 

In einer Bibliotheksanwendung sollen Bücher verwaltet werden. 

- Jedes Buch hat einen Titel und einen Autor. 

- Diese beiden Attribute werden im Konstruktor gesetzt und man soll mit 

Getter-Methoden darauf zugreifen können. 

class Book { 

public: 

Book(const string& title, const string& author); 

string& getTitle(); 

string& getAuthor(); 

private: 

string title; 

}; 

string author; 





Beispiel 

Die Unit-Tests für die Klasse Book werden in einer eigenen Klasse 

BookTest definiert und implementiert. 

Beispiele für Tests: 

- Es gibt einen Test, der prüft, ob ein getTitle() den korrekten Titel 

zurückliefert. 

- Es gibt einen weiteren Test, der prüft, ob getAuthor() den korrekten Autor 

zurückliefert. 

“If I had one test broken, I wanted one problem. If I had two tests 

broken, 

wanted two problems.” 

Quelle: K. Beck „Test-Driven Development“, Addison-Wesley, 2003 





Beispiel: Definition der Testklasse (BookTest.h) 

Die Klasse BookTest ist von TestFixture abgeleitet. Wir definieren die Tests 

unter Zuhilfenahme von vorgefertigten Macros. Hierzu muss die Datei 

HelperMacros.h inkludiert werden. 

#include 

#include 

#include "Book.h" 

using namespace std; 

class BookTest : public CPPUNIT_NS :: TestFixture 

{ 

// hier geht es auf der nächsten Folie weiter 

}; 






Die Definition der Tests beginnt mit dem Makro CPPUNIT_TEST_SUITE und 

endet mit dem Makro CPPUNIT_TEST_SUITE_END. 

- Dem Makro CPPUNIT_TEST_SUITE muss der Name der Testklasse, hier also BookTest 

übergeben werden. 

- Zwischen diesen beiden Makros werden die Namen der einzelnen Testmethoden mit dem 

Makro CPPUNIT_TEST definiert. Hier gibt es zwei Testmethoden, titleTest() und 

authorTest(). 

CPPUNIT_TEST_SUITE(BookTest); 

CPPUNIT_TEST(titleTest); 

CPPUNIT_TEST(authorTest); 

CPPUNIT_TEST_SUITE_END(); 

- Diese Makros erzeugen eine statische Methode suite(), welche die aufgezählten 

Testmethoden enthält. 






Die beiden Methoden setUp() und tearDown() dienen dazu, eine 

Testvorrichtung auf- bzw. wieder abzubauen. In unserem Fall brauchen wir 

für die Testvorrichtung lediglich ein Buch und den dazugehörigen Titel und 

Autor. Des Weiteren sind die zwei Testmedoden titleTest() und authorTest() 

definiert. 

public: 

void setUp(); 

void tearDown(); 

void titleTest(); 

void authorTest(); 

private: 

string title; 

string author; 

Book *b; 





Beispiel: Implementation der Testklasse (BookTest.cpp) 

Damit eine Testklasse von dem CppUnit Framework auch gefunden wird, 

muss sie registriert werden. Hierzu gibt es ein Makro. 

CPPUNIT_TEST_SUITE_REGISTRATION(BookTest); 

Bei jedem Aufruf einer Testmethode wird zuerst setUp(), danach die eigentliche Testmethode und 

im Anschluss daran tearDown() aufgerufen. Somit wird jede Testmethode in einer eigenen, 

wohldefinierten Testvorrichtung ausgeführt. 

void BookTest :: setUp() { 

title = "Extreme Programming Explained"; 

author = "Kent Beck"; 

b = new Book(title, author); 

} 

void BookTest :: tearDown() { 

delete b; 

} 





Beispiel: Implementation der Testklasse (BookTest.cpp) 

In der Testmethode titleTest() wird überprüft, ob der mit getTitle() 

zurückgelieferte Titel tatsächlich dem vorher bekannten Titel entspricht. 

- Hierzu wird das Makro CPPUNIT_ASSERT_EQUAL verwendet, welches zwei Parameter 

besitzt. Der erste Parameter ist der zu erwartende Wert (expected value), und der zweite 

Parameter ist der tatsächliche Wert (actual value). Wenn beide Werte gleich sind, war der 

Test erfolgreich. 

- Mit CPPUNIT_ASSERT(Ausdruck) kann man einen beliebigen Ausdruck testen. Er muss 

wahr sein wenn der Test erfolgreich sein soll. Z. B. 

“CPPUNIT_ASSERT(kalk.squareRoot(9) == 3);“ 

Weitere Zusicherungs-Makros sind in TestAssert.h definiert. 

void BookTest :: titleTest() { 

CPPUNIT_ASSERT_EQUAL(title, b->getTitle()); 

} 

void BookTest :: authorTest() { 

CPPUNIT_ASSERT_EQUAL(author, b->getAuthor()); 

} 





Beispiel: Das eigentliche Testprogramm (test.cpp) 

Damit die Tests gestartet werden können benötigt man einen TestRunner. 

- Es gibt verschiedene TestRunner für die Textkonsole und graphische Oberflächen. 

- Mit registry.makeTest() erhält man eine Testsuite mit allen registrierten Tests. 

#include 

#include 

using namespace std; 

main() { 

CppUnit::TestFactoryRegistry &registry = 

CppUnit::TestFactoryRegistry::getRegistry(); 

} 

CppUnit::TextUi::TestRunner runner; 

runner.addTest(registry.makeTest()); 

bool rc = runner.run(); 

return !rc; 





Beispiel: Praktikumsaufgabe 3, 4 


Eclipse-Projekt 

„ShopWithCppUnit“ 



Kapitel 3.4 Junit, CppUnit 

Weitere Informationen / Links 

- Johannes Link, Softwaretests mit Junit, Techniken der testgetriebenen 

Entwicklung, dpunkt.verlag, 2005 

- CppUnit-Homepage: http://sourceforge.net/projects/cppunit 

- CppUnit-Tutorial: 

http://www.evocomp.de/tutorials/tutorium_cppunit/howto_tutorial_cppunit.html 

- Wikipedia – CppUnit: 

http://de.wikipedia.org/wiki/CppUnit

Testen, Testmanagement, Unit-Tests - beim Fachbereich Informatik ...

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?