Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciencest 14.04.2016
Systematisches Testen von Software
▶ SWE-IPM
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
2
Sie kennen
▶ Methoden und Techniken zur Beurteilung der Qualität von Lieferobjekten
▶ relevante Testverfahren in IT-Projekten
▶ die Unterschiede zwischen Reviews, Audits und Tests
▶ die Problematik der selektiven Wahrnehmung
▶ den Einfluss von Fehlerentstehungs- und Behebungszeitpunkt auf die
Kosten
Sie können
▶ eine Teststrategie und ein Testkonzept unter Risikobetrachtungen erstellen
▶ Techniken angemessen einsetzen um Ursachen von Qualitätsabweichungen
zu ermitteln
▶ Testergebnisse protokollieren, auswerten und darstellen
Kursziele
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
3
1. Einführung ins Thema Testing
2. Review
3. Verifikation und Validierung
4. Testebenen, Teststufen, Testarten
5. Der Testprozess
6. Das Testkonzept
7. Black Box Testing
1. Äquivalenzklassenbildung
2. Grenzwertanalyse
3. Intuitive Testfallermittlung
8. White Box Testing
9. Zustandsbezogene Tests
10. Entscheidungstabellentechnik /
Ursachen-Wirkungs-Analyse
11. Testendkriterien
Inhalt
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
4
▶ Erfahrungen aus den vergangenen Kursen:
▶ Für den Prüfungserfolg ist wichtig, dass die Übungen gelöst und verstanden wurden.
▶ Obwohl die Kursunterlagen während der Prüfung verwendet werden dürfen, erweisen
sie sich nur als bedingt nützlich, wenn die Theorie nicht verstanden wurde.
▶ Es wird unterschätzt, dass nach Abschluss des Kurses für die Prüfungsvorbereitung
wenig Zeit zur Verfügung steht.
▶ Spezielle Lehrmethode für die Kapitel 7 bis 10:
▶ Die Theorie und die begleitenden Übungen sind vorgängig zum Unterricht im
Selbststudium zu lösen und Fragen dazu mit in den Unterricht zu nehmen.
▶ Während dem Unterricht besprechen die Studierenden ihre Fragen in Problem-
Solving-Sessions.
▶ Der Dozent steht für Fragen zur Verfügung.
▶ Unterrichtsvorbereitung (durch die Studierenden im Selbststudium):
▶ Für den 2. Halbtag Testing:
▶ Kapitel 7 - Black Box Testing
▶ Für den 3. Halbtag Testing:
▶ Kapitel 8 - White Box Testing,
▶ Kapitel 9 - Zustandsbezogene Tests,
▶ Kapitel 10 - Entscheidungstabellentechnik / Ursachen-Wirkungs-Analyse
Vorbereitungsaufträge
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
5
1. Einführung ins Thema Testing
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
6
▶ Welches sind die teuersten Fehler?
Zusammenhang Fehlerentstehungs- und
Behebungszeitpunkt
Quelle: Vereinfacht nach Boehm 1981 / Frühauf et.al. 1998
Codierung Modultest
Anforderungen Abnahmetest / Betrieb
Design Integrationstest / Systemtest
Herstellung Testen
Zeit
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
7
Auf welcher Teststufe werden welche Fehler gefunden?
▶ Fehler werden auf der Entwicklungsstufe gefunden, auf der sie
begangen wurden.
Siehe auch Lehrbuch s. 349
Teststufe Codierungsfehler Entwurfsfehler
Modultest
Integrationstest
& Systemtest
Abnahmetest
& Betrieb
Total 98% 95%
65% 0%
30% 60%
3% 35%
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
8
Ursachen von Fehlerkosten verteilt auf die Projektphasen
Auf welche Projektphasen sind die meisten Fehlerkosten
zurückzuführen?
▶ Rund drei Viertel der Fehler entstehen in der Analyse- & Design-Phase
▶ Mit welchen Methoden können diese Fehler gefunden werden?
Quelle: V.Basili, An empirical Investigation CACM, 2004
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
9
Relative Fehlerkostenentwicklung
Quelle: O.Bürgi, Systematisches Testen von Software, 2012
Lesebeispiel: Ein Fehler in den Anforderungen dessen Behebung zum
Zeitpunkt des Anforderungsreviews 1 Fr. gekostet hätte, kostet zum
Zeitpunkt der Codierung 20 Fr. (Bei einem grossen Projekt)
20
▶ Die Kosten eines Fehlers in den Anforderungen steigen exponentiell
zu seiner Verweildauer im Code!
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
10
Tests sind nicht die einzige Maßnahme im Qualitätsmanagement der
Softwareentwicklung, aber oft die letztmögliche (vor Inbetriebnahme)!
▶ Je später Fehler entdeckt werden, desto aufwändiger ist ihre
Behebung.
▶ Daraus lässt sich der Umkehrschluss ableiten: Qualität muss im
ganzen Projektverlauf implementiert werden und kann nicht am
Schluss 'eingetestet' werden.“
Spezialfall Softwareentwicklung?
▶ Beim Testen in der Softwareentwicklung wird in der Regel eine mehr
oder minder große Fehleranzahl als 'normal' akzeptiert.
▶ Hier herrscht ein erheblicher Unterschied zur Industrie: Dort werden
im Prozessabschnitt 'Qualitätskontrolle' oft nur noch in
Extremsituationen Fehler erwartet.
Fazit zur Fehlerkostenentwicklung
Quelle: M. Pol, T. Koomen, A. Spillner: Management und Optimierung des Testprozesses, dpunkt.Verlag
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
11
Wie hoch ist der Anteil der QS-Massnahmen am
Gesamtentwicklungsaufwand?
Quelle: Jones, 1991
▶ Je grösser das Projekt, desto wichtiger wird Qualitätssicherung und
Dokumentation
0%
50%
100%
En
twic
klu
ng
sau
fwan
d
Aufwand in [PM]
Relative Anteile am Entwicklungsaufwand:
Dokumentation
Codierung
AnalytischeQualitätssicherung
(PM=Personenmonate)
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
12
▶ Im Verhältnis zum Gesamtprojektaufwand wird der Testaufwand im
Durchschnitt der Jahre auf ungefähr 16% geschätzt.
Testaufwand im Verhältnis zum Gesamtaufwand
Quelle: swissQ, Trends & Benchmarks 2016 (Datenbasis: 450 ausgefüllte Online-Fragebogen)
Lesebeispiel
▶ 28.7% der Befragten gaben an, dass
der Testaufwand 11-15% des
Gesamtaufwandes beträgt.
▶ 25.7% der Befragten gaben an, dass
der Testaufwand 16-20% des
Gesamtaufwandes beträgt.
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
13
▶ Im Verhältnis zum Entwicklungsaufwand wird der Testaufwand im
Durchschnitt der Jahre auf ungefähr 25% geschätzt.
Testaufwand im Verhältnis zum Entwicklungsaufwand
Quelle: swissQ, Trends & Benchmarks 2016 (Datenbasis: 450 ausgefüllte Online-Fragebogen)
Lesebeispiel
▶ 30.5% der Befragten gaben an, dass
der Testaufwand im Verhältnis zum
Entwicklungsaufwand 21-30% beträgt.
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
14
▶ Wer hat Recht?
Was ist Testen?
Quelle: O.Bürgi, Systematisches Testen von Software, 2012
«Beim Testen lässt man ein Programm laufen, mit der Absicht, Fehler zu
finden»
Myers, 1979
“Testing is the process of establishing Confidence that a program (or
system) does what it is supposed to.”
Hetzel, 1984
“Unter Testen versteht man den Prozess des Planens, der Vorbereitung und
der Messung, mit dem Ziel, die Eigenschaften eines IT-Systems festzustellen
und den Unterschied zwischen dem tatsächlichen und dem erforderlichen
Zustand aufzuzeigen.”
Pol, Koomen, Spillner, 2002
“Testen ist der Prozess des Verifizierens und Validierens eines Systems oder
seiner Komponenten.»
Bresser, 2004
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
15
Wer hat Recht?
Quelle: O.Bürgi, Systematisches Testen von Software, 2012
Myers hat Recht!
Test ist ein Verfahren, bei dem ein Programm mit dem Ziel zur Ausführung
gebracht wird, sein Fehlverhalten zu demonstrieren. Der Test zeigt auf,
unter welchen Randbedingungen das Programm von den Anforderungen
abweichend reagiert.
Auch Hetzel hat Recht!
Bei der Abnahme wird ebenfalls das Testverfahren angewendet. Deshalb
spricht man auch von Abnahmetests. Der Lieferant ist bemüht, die
Tauglichkeit des Programms zu demonstrieren, der Kunde seinerseits ist
bemüht, Vertrauen aufzubauen.
Auch Pol, Koomen und Spillner haben Recht!
Das Testen ist ein Prozess. Die Tests müssen geplant, spezifiziert,
durchgeführt, protokolliert und ausgeführt werden.
Bemerkenswert: Als Messgröße gilt 'der erforderliche Zustand', nicht nur die
(möglicherweise fehlerhafte) Spezifikation
Auch Bresser hat Recht!
Es wird nicht nur geprüft, ob das System gemäss Spezifikation erstellt
wurde, sondern auch, ob es den Anforderungen des Kunden entspricht
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
16
▶ Vollständiges Testen ist (ab einer gewissen Grösse) unmöglich
▶ Deshalb ist es um so wichtiger, dass man die zur Verfügung stehenden
Mittel in das systematische Testen investiert!
▶ Testen ist kreativ und anspruchsvoll
▶ Frage: "Wie kann ich das Programm zu einem Fehler verleiten"
▶ Tests müssen geplant sein
▶ Was ist der Zweck des Tests?
▶ Welche Ergebnisse erwarte ich von meinem Programm?
▶ Wie überprüfe ich diese Ergebnisse?
▶ Wie dokumentiere ich die Testergebnisse nachvollziehbar?
▶ Ein Programmierer sollte nie versuchen, sein eigenes Programm zu testen.
Stimmt diese Aussage?
Grundsätze zum Thema Testen
Quelle: O.Bürgi, Systematisches Testen von Software, 2012
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
17
▶ Schauen Sie sich die vier kurzen Videos zur selektiven Wahrnehmung an und
beantworten Sie die Fragen.
▶ Welches Fazit ziehen Sie daraus für das Testing?
Übung: Selektive Wahrnehmung
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
18
2. Review
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
19
Quelle: Steve Maguire, Nie wieder Bugs, 1994 / eigene Ergänzungen / Lehrbuch s. 347
Vergleich von Audit, Review und Test
Audit:
Überprüfung von Verfahren und Abläufen
Beurteilung des Projekts und des Projektmanagement Prozesses
Prüft nur das Vorhanden sein der Dokumente aber nicht deren Inhalt
Die «richtigen Dinge» tun.
Review (statische Tests):
Überprüfung des Inhalts eines Dokuments
Beurteilung des Produkts.
Die Dinge «richtig tun»
Kann ca. 70% der Fehler finden!
Testen (dynamische Tests):
Ausführung des Programms
Ziel 1: Fehler finden
Ziel 2: Vertrauen finden (Abnahmetest)
Kann ca. 50% der Fehler finden
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
20
Quelle: O.Bürgi, Systematisches Testen von Software, 2012
Review-Formen
Schriftliches Stellungnahme Verfahren
Häufig informell
Häufig ohne Checklisten alle schauen alles quer durch
Geeignet für breiten Teilnehmerkreis
Walkthrough
Vor allem für Code geeignet Wissenstransfer
Der Autor erklärt seinen Code
Technisches Review
Formale, strukturierte Vorgehensweise
Gutachter prüfen anhand spezifischer Checklisten
Fehler nur aufdecken, nicht lösen wollen! Sonst besteht
die Gefahr ausufernder Diskussionen.
Straffe Führung und gute Vorbereitung ist das A und O
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
21
Quelle: O.Bürgi, Systematisches Testen von Software, 2012
Welche Unterlagen werden für ein technisches Review
benötigt?
Lieferung
Prüfling, Gegenstand der Untersuchung
Checklisten
Hilfsmittel für die Gutachter
Richtlinien
Normen und Vorschriften
für die formale Prüfung
Vorgabe
Referenzunterlagen für
die inhaltliche Prüfung
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
22
cvcvcvBessere Streuung der
Produkte-Kenntnis
Vereinheitlichung der
Qualität
Ausbildung neuer
Mitarbeitenden
Verbesserung des
Arbeitsklimas
cvcvcvBessere Streuung
der Produkte-Kenntnis
Vereinheitlichung der
Qualität
Ausbildung neuer
Mitarbeitenden
Verbesserung des
Arbeitsklimas
«Risiken und Nebenwirkungen» von Reviews
Probleme
▶ Es braucht „die Besten“
(und die haben keine Zeit)
▶ „Warum soll ich heute in
etwas investieren, dessen
Resultate ich erst in einem
Jahr sehe?“
▶ „Macht endlich vorwärts,
wir sind bereits in
Verzug…“
Nebeneffekte
▶ Bessere Streuung der
Produkte-Kenntnis
▶ Vereinheitlichung der Qualität
▶ Ausbildung neuer
Mitarbeitender
▶ Verbesserung des
Arbeitsklimas (Kritikfähigkeit)
Quelle: O.Bürgi, Systematisches Testen von Software, 2012
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
23
▶ Reviews in der
Konzeptphase führen
zu Einsparungen in der
Impementations- und
Testphase.
▶ Nicht möglichst viel
reviewen sondern die
richtigen Artefakte
Wirtschaftlichkeit von Reviews
Quelle: Fagan, 1986
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
24
Empfehlung über Umfang von Reviews
Insgesamt etwa 25% bis 40% aller Dokumente reviewen
▶ Alle Teilergebnisse auf der Systemebene
Bsp.: Systemarchitektur
▶ Teile mit hohem Risiko, Bsp. zeitkritische und
speicherplatzkritische Teile (Achtung: optimiere keinen Code,
dessen Performance du nicht vorher gemessen hast!)
▶ Teile, die mehrere Mitarbeitende betreffen (Schnittstellen)
▶ Codereview v.a. für Wissenstransfer / Good Programming
Practice (sofern nicht bereits durch Pair Programming
abgedeckt)
Quelle: O.Bürgi, Systematisches Testen von Software, 2012
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
25
3. Verifikation und Validierung
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
26
Ziel
▶ Überprüfen ob das Lieferergebnis einer Phase (Spezifikation, Komponente,
System) funktional äquivalent zur vorherigen Phase ist.
▶ Formale Prüfung ob die Lieferung der zugrundeliegenden Spezifikation
entspricht.
Problem
▶ Kundenanforderungen sind meist nicht formal, deshalb sind sie kein geeigneter
Input für die Verifikation.
▶ Spezifikationen sind nur selten vollständig
▶ Nur die nach der Spezifikationserstellung entstandenen Fehler können gefunden
werden. Deshalb kein Nachweis der Fehlerfreiheit.
Techniken zur Verifikation
▶ Alle formalen Prüfungen (Audit, Review, formale Tests)
Verifikation
IEEE Standard Glossary of Software Engineering Terminology, IEEE Std 610.12-1990
IEEE Std 610.12
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
27
Ziel
▶ Überprüfen ob das Lieferergebnis einer Phase (Spezifikation, Komponente,
System) konsistent ist mit den Anforderungen des Kunden und diese erfüllt.
Probleme
▶ Anforderungen meist informell, unpräzise, unvollständig, widersprüchlich.
▶ Automatisierung der Prüfung erst ab Stufe Implementation möglich.
Techniken zur Validierung
▶ Review der Spezifikation.
▶ How to demo erstellen (dadurch indirekt Validierung der Anforderungen).
▶ Sprint Review (Validieren der Implementation).
▶ Acceptance Tests (Abnahmetests durch den Kunden).
▶ Systemtests soweit diese Funktionale / Nichtfunktionale Anforderungen testen.
Validierung
IEEE Standard Glossary of Software Engineering Terminology, IEEE Std 610.12-1990
IEEE Std 610.12
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
28
▶ Nur die Validierung prüft gegen das zugrunde liegende Problem
Validierung vs. Verifikation
Quellen: 2005 Martin Glinz /
Spezifikation Programm
Implementierung
Verifikation
Problem
(Business Requirements)
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
29
Bau des Lorraineviadukts, 1941
• Belastungsprobe des Lehrgerüsts mit Sandsäcken
• Belastungsprobe des Viadukts mit 4 Dampfloks
Quellen: SBB Historic / Lueger-1904, Lexikon der gesamten Technik http://www.sbbarchiv.ch
▶ Ist das ein Test?
▶ Ist das eine Verifikation?
▶ Ist das eine Validierung?
Beantworten Sie die Fragen anhand des Texts auf der nächsten Seite
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
30
Belastungsprobe bei Brücken
Test, Verifikation oder Validierung?
▶ Belastungsproben werden bei Brücken vor deren Inbetriebsetzung vorgenommen und
haben bei dem heutigen Stande der Brückenbautechnik wohl weniger den Zweck, die
Haltbarkeit einer Brückenkonstruktion nachzuweisen, als vielmehr durch das Maß
der Formänderungserscheinungen ein Urteil über die Güte zu gewinnen und die
Überzeugung zu verschaffen, dass keine offenkundigen Mängel in dem Entwurfe
und in der Ausführung der Brückenkonstruktion vorhanden sind.
▶ Bei Eisenbahnbrücken von größerer Spannweite wird ein eigner Belastungszug
zusammengestellt, der für Hauptbahnen aus drei Lokomotiven der schwersten Gattung
samt Schlepptendern und vollbelasteten Güterwagen besteht. Dieser wird zuerst
langsam so weit auf die Brücke gefahren, dass die größte Anstrengung für die
Trägermitte hervorgebracht wird. In dieser Stellung bleibt der Zug eine bestimmte Zeit
ruhig stehen, worauf derselbe nach erfolgter Messung der Einsenkungen mit mässiger
Geschwindigkeit und dann in Schnellfahrt über die Brücke hin und zurück bewegt wird.
▶ Vor Ausführung der Proben sind von der Brücke unabhängige Fixpunkte und eine
Anzahl von Höhenmarken an den Brückenträgern anzubringen, um die eintretenden
Formänderungen richtig messen zu können.
Zeitaufwand: 2 min, Diskussion im Plenum: 3 min
Lueger 1904: Lexikon der gesamten Technikhttp://www.zeno.org/Lueger-1904/A/Belastungsprobe
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
31
4. Testebenen, Teststufen, Testarten
Ein Versuch, etwas Klarheit in den Begriffswildwuchs zu bringen
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
32
System-Ebene
Teilsystem-Ebene
Komponenten-Ebene
Modul-Ebene
Beta
Gamma Gamma
Delta Delta Delta Delta Delta Delta Delta
Gamma Gamma
Beta Beta
Alpha
Testebenen abgeleitet von der Softwarearchitektur
Quelle: O.Bürgi, Systematisches Testen von Software, 2012
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
33
Programmierung
Komponententest
Teststufen abgeleitet vom V-Modell
Quelle: Basiswissen Softwaretest, dpunkt.Verlag
siehe auch Lehrbuch s. 182
Anforderungs-
Definition
Funktionaler
Systementwurf
Technischer
Systementwurf
Komponenten-
Spezifikation
Integrationstest
Systemtest
AbnahmetestValidierung
Verifizierung
Verifizierung
Verifizierung
(Validierung)
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
34
Beschreibung der Teststufen
Quelle: Basiswissen Softwaretest, dpunkt.Verlag
Der Integrationstest prüft…
…ob Gruppen von Komponenten gemäss
technischem Systementwurf zusammenspielen
Der Systemtest prüft…
…ob das System als Ganzes die spezifizierten
funktionalen und nichtfunktionale
Anforderungen erfüllt.
Der Abnahmetest prüft…
…ob das System aus Kundensicht die
vertraglich vereinbarten Leistungsmerkmale
aufweist
Der Komponententest prüft…
…ob jede einzelne Komponente für sich die
Vorgaben seiner Spezifikation erfüllt
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
35
Praxisbeispiel Postfinance
Einbettung des Testings im V-Modell
Quelle: Postfinance
Architekturmanagement PF
V-Modell
PLAN DESIGN BUILD INTEGRATION
Software Integration
Software Solution
BRD SRS /
SSt
Spez.
Entwicklungs-Auftrag
BRD
/
SRS
Requirements Engineering
Code/SW-
Package
Release-Package
Testabschlussbericht System- und Integrationstest als Teil des Abnahmeprotokolls
Scope
Doc
Legende:PAK= Projekt-AuftragRC = Requirements CatalogBRD = Business Requirements DocumentSRS = System Requirements SpecificationSSt Spez. = Schnittstellen Spezifikation
Projektmanagement PF
Testing
Testing Aktivitäten
BRD mit Testidee
AuftragRealisierung
PAR
RE-Management PF
Testresultate pro
Reqression.
RCPAK Test-abschluss-
bericht
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
36
Informelle Tests Formelle Tests
Planung Eher nein Ja
Auswahl der Testfälle Zufall Methode
Intuitives Vorgehen Ja In Ergänzung
Testvorschrift Nein Ja
Kriterium für Testbeendigung Nein Ja
Nachweis mit Testbericht Nur begrenzt möglich Ja
Wiederholbarkeit des Tests Nur begrenzt möglich Ja
Informelle Tests versus Formelle Tests
Quelle: O.Bürgi, Systematisches Testen von Software, 2012
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
37
Big Bang Inkrementell
Alles auf einmal testen
(sämtliche Teile werden getestet,
z.B. End to End)
Schritt für Schritt testen,
immer wieder, immer etwas mehr
(Benötigt Stubs / Drivers)
Gesamtes System ist verfügbar
Bottom-Up / Top-Down /
Das Wichtigste zuerst / Das Verfügbare
zuerst
Typisch für Systemtests und
Abnahmetests
Typisch für Modultests und
Integrationstests
Eher für die Validierung geeignet
(Erfüllt das Produkt die gestellten
Anforderungen)
Eher für die Verifizierung
(Ist das Phasenergebnis relativ zu seiner
Spezifikation korrekt und vollständig?)
Big Bang Testen versus Inkrementell Testen
Quelle: O.Bürgi, Systematisches Testen von Software, 2012
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
38
Top down Bottom up
Haupt- vor Detailfunktionen testen Detailfunktionen zuerst testen
Untergeordnete Routinen werden
beim Test zunächst ignoriert oder
(mittels „Stubs“) simuliert
Übergeordnete Funktionen oder
Aufrufe werden mittels "Testdriver"
simuliert
Top down Testen versus Bottom up Testen
Quelle: O.Bürgi, Systematisches Testen von Software, 2012
S tum pf S tum pf
P rüfling
G e testet
G e tes te t G e tes te t
P rü flin g
T re ib e r
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
39
Black Box TestingWhite Box Testing
(= Glass Box Testing)
Der Programmcode liegt nicht vor. Der Programmcode liegt vor
Ableitung der Testfälle ausschliesslich
aus Dokumenten wie Anforderungen,
Spezifikation, Benutzerhandbuch.
Ableitung der Testfälle aus einzelnen
Methoden und Routinen (Beweise
durch Widersprüche)
Möglichst vollständige Funktions-
Abdeckung
Möglichst vollständige Code-
Abdeckung
Erfordert keine
Programmierkenntnisse
Erfordert Programmierkenntnisse
Findet nicht spezifizierte Features nur
durch Zufall (z.B. Easter Eggs)
Kann nicht spezifizierte Features
aufdecken
Typisches Vorgehen für Tests durch
eine unabhängige Testabteilung
Typisches Vorgehen für Unit-Tests
welche durch die Entwickler selber
erstellt werden
White Box Tests versus Black Box Tests
Quelle: O.Bürgi, Systematisches Testen von Software, 2012
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
40
▶ Lasttest, Volumentest, Massentest:
▶ Messen des Systemverhaltens in Abhängigkeit steigender Systemlast /
Verarbeitungsvolumen
▶ Performancetest
▶ Messen der Verarbeitungsgeschwindigkeit, meistens in Abhängigkeit
steigender Last
▶ Stresstest
▶ Beobachten des Systemverhaltens bei Überlastung
▶ Test auf Stabilität/Zuverlässigkeit
▶ Beobachtet z.B. die Memory-Belastung im Dauerbetrieb
▶ Test auf Sicherheit (Penetration-Tests)
▶ Test auf Benutzungsfreundlichkeit (Usability-Tests)
▶ Prüfung der Dokumentation
▶ Prüfung auf Änderbarkeit, Wartbarkeit
▶ Z.B. Verständlichkeit und Aktualität der Entwicklerdokumentation
▶ Z.B. Struktur der Systemarchitektur (modular v.s. monolithisch)
Testen nichtfunktionaler Anforderungen
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
41
5. Der Testprozess
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
42
Fundamentaler Testprozess
Quelle für Teststrategie: M. Pol, T. Koomen, A. Spillner: Management und Optimierung des Testprozesses
Quelle für Testprozess: British Standard 7925-2, Software Testing
Planung
Spezifikation
Durchführung der Tests
Beginn
Protokollierung
Auswertung
Ende
Erstellen der Teststrategie:
Mittels Risikoabschätzung
beurteilen, wie kritisch das
Auftreten eines Fehlers in
einem Systemteil ist.
Unter Berücksichtigung der
verfügbaren Ressourcen
definieren, wie intensiv jedes
Systemteil getestet werden
kann oder muss.
Definieren mit welchem
Vorgehen und mit welcher
Priorität jedes Systemteil
getestet werden soll.
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
43
Zusammenhang der Dokumente und Verfahrensschritte
nach IEEE 829
Quelle: IEEE Standard for Software and System Test Documentation (IEEE Std. 829-2008)http://de.wikipedia.org/w/index.php?title=Softwaretest
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
44
▶ Testplan
▶ Beschreibt Umfang,
Vorgehensweise, Terminplan,
Testgegenstände.
▶ Testdesignspezifikation
▶ Beschreibt die im Testplan
genannten Vorgehensweisen im
Detail.
▶ Testfallspezifikationen
▶ Beschreibt die
Umgebungsbedingungen,
Eingaben und Ausgaben eines
jeden Testfalls.
▶ Testablaufspezifikationen
▶ Beschreibt, wie jeder Testfall
durchzuführen ist.
▶ Testobjektübertragungsbericht
▶ Protokolliert, wann welche
Testgegenstände an welche
Tester übergeben wurden.
▶ Testprotokoll
▶ Listet chronologisch alle
relevanten Vorgänge bei der
Testdurchführung.
▶ Testvorfallbericht
▶ Listet alle Ereignisse, die eine
weitere Untersuchung
erforderlich machen.
▶ Testergebnisbericht
▶ Beschreibt und bewertet die
Ergebnisse aller Tests
Beschreibung der Testdokumente nach IEEE 829
Quelle: IEEE Standard for Software and System Test Documentation (IEEE Std. 829-2008)http://de.wikipedia.org/w/index.php?title=Softwaretest
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
45
Schnittstellen zum Softwareentwicklungsprozess
Quelle: O.Bürgi, Systematisches Testen von Software, 2012, Ergänzungen Friedli
Testvorbereitung
Ausführung
Auswertung
Anforderungen
erfülltFreigabe
Fehlersuche
Art des
MangelsÄnderung der
AnforderungenFehler in
Implementierung
Fehler in Testdaten/
Testumgebung
FehlerbehebungAnpassen
TestumgebungChange Request
Test-
Wiederholung
ja
nein
Anpassen
Benutzerdoku
Fehl-
Bedienung
Systementwicklungsprozess
Prüf-/Testprozess
Legende:
Change Management
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
46
Schnittstellen zum Projektmanagement Prozess
Quelle: O.Bürgi, Systematisches Testen von Software, 2012
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
47
▶ Mit der
Testfallermittlung
sind weniger als 50%
der Befragten
zufrieden.
▶ Die
Testdurchführung
hingegen schneidet
eindeutig am besten
ab.
Zufriedenheit mit Testaktivitäten
Quelle: swissQ, Trends & Benchmarks 2016 (Datenbasis: 450 ausgefüllte Online-Fragebogen)
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
48
▶ Die frühe Involvierung des Testings wird als wichtigster Erfolgsfaktor
angesehen.
▶ Wenn das Testing bereits bei der Anforderungserhebung aktiv beteiligt ist,
steigt die Qualität der Anforderungen und das Know-How, welche wiederum zu
den wichtigsten Erfolgsfaktoren gezählt werden.
Erfolgsfaktoren im Testing
Quelle: swissQ, Trends & Benchmarks 2016 (Datenbasis: 450 ausgefüllte Online-Fragebogen)
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
49
6. Das Testkonzept
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
50
1. Testkonzeptbezeichnung
▶ Eindeutige Referenz.
2. Einführung
▶ Kurze Darstellung des Projekthintergrundes.
▶ Ausgangsdokumente (Normen, Unternehmensstandards,
Projektstandards, Kundenstandards, Spezifikationen) die das Testkonzept
referenziert oder umsetzen muss.
3. Testobjekte
▶ Kurze Darstellung aus welchen Teilen/Konzepten die zu testende Software
besteht.
▶ Auflistung derjenigen Komponenten daraus, die Gegenstand des Tests
sind.
▶ Auflisten von Systemteilen, die nicht getestet werden.
Testkonzept nach IEEE 829 (1 von 5)
Quelle: IEEE Standard for Software and System Test Documentation (IEEE Std. 829
Hinweis für das Integrationsprojekt:
▶ Es wird empfohlen, die übergeordnete
Planung im Teil Projektmanagement zu
machen.
▶ Für den Teil Testing im Integrationsprojekt
ist die Erstellung der fett unterstrichenen
Artefakte zweckmässig.
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
51
4. Zu testende Leistungsmerkmale
▶ Identifiziert, welche Funktionen und Eigenschaften des Systems zu testen
sind.
▶ Ev. Verweis auf die detaillierten Testspezifikationen.
▶ Ev. Zuordnung von Testobjekten zu Teststufen.
5. Leistungsmerkmale, die nicht getestet werden
▶ Klarstellen, welche Aspekte nicht getestet werden sollen oder können (z.B.
wegen Ressourcenmangel, technischen Gründen).
6. Teststrategie
▶ Definition der Testziele, basierend auf einer Risikoanalyse. Diese klärt,
welche Risiken drohen, wenn Fehler nicht gefunden werden.
▶ Welche Testziele sind unverzichtbar, welche weniger wichtig?
▶ In welcher Reihenfolge werden die Themen angegangen?
▶ Wann werden welche Methoden auf welche Objekte angewendet?
▶ Erklärung, warum diese Methoden geeignet sind um die Testziele zu
erreichen?
Testkonzept nach IEEE 829 (2 von 5)
Quelle: IEEE Standard for Software and System Test Documentation (IEEE Std. 829
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
52
7. Abnahmekriterien (Testendkriterien)
▶ Anzahl gelaufene Tests.
▶ Anzahl noch offener Fehler.
▶ Schweregrad der offenen Fehler.
8. Kriterien für Testabbruch und Testfortsetzung
▶ Wann dürfen Tests abgebrochen und die Lieferung zurückgewiesen
werden, weil die Software nicht testwürdig ist?
▶ Welche Kriterien müssen erfüllt sein, dass die Software testwürdig ist? (Ev.
Definition spezieller Factory Acceptance Tests).
9. Testdokumentation
▶ Welche Dokumente werden erstellt?
▶ An wen und in welcher Form werden die Ergebnisse (inkl.
Planungsdokumente) kommuniziert?
Testkonzept nach IEEE 829 (3 von 5)
Quelle: IEEE Standard for Software and System Test Documentation (IEEE Std. 829
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
53
10. Testaufgaben
▶ Auflistung aller Aufgaben, die zur Planung und Durchführung der Tests
notwendig sind.
11. Testumgebung/Testinfrastruktur
▶ Auflistung der Bestandteile der Testinfrastruktur, z.B. Testplattformen,
Ausstattung der Testerarbeitsplätze, Tools, benötigte
Netzwerkinfrastruktur für die Lasttests etc.
12. Verantwortlichkeiten/Zuständigkeiten
▶ Organisatorische Einbindung des Testpersonals in das Projekt,
Weisungsbefugnisse,
▶ Zuteilung des Personals zu Testgruppen, Teststufen.
13. Personal, Einarbeitung, Ausbildung
▶ Zur Planumsetzung benötigte Personalausstattung, (inkl. Kunden, und
Entwickler zur Testunterstützung).
▶ Massnahmenplan zur Ausbildung des Personals.
Testkonzept nach IEEE 829 (4 von 5)
Quelle: IEEE Standard for Software and System Test Documentation (IEEE Std. 829
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
54
13. Zeitplan / Arbeitsplan
▶ Grober Zeitplan der Testaktivitäten auf Meilensteinebene
Abstimmung zwischen Testmanager und Projektmanager!
14. Planungsrisiken und Unvorhergesehenes
▶ Probleme, die bei der Umsetzung des Testkonzepts auftauchen
könnten.
Liste von Risiken und Massnahmen. Diese Liste jeweils anlässlich der
Teststatusberichte aktualisieren.
15. Genehmigung / Freigabe
▶ Personen/OEs, die das Testkonzept freigeben müssen.
16. Glossar (in Ergänzung zu IEEE 829, da im Testbereich ein ziemlicher
Begriffswildwuchs herrscht)
▶ Im Projekt verwendete Testfachbegriffe.
▶ Was wird z.B. unter einem Lasttest verstanden und was unter einem
Performancetest?
Testkonzept nach IEEE 829 (5 von 5)
Quelle: IEEE Standard for Software and System Test Documentation (IEEE Std. 829
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
55
Gedanken zur Auswahl der Testfälle
Quelle: O.Bürgi, Systematisches Testen von Software, 2012
Fazit:
Ein erfolgreicher Testfall findet einen Fehler!
Wegweisende Fragestellung zur Auswahl der Testfälle:
Welche Teilmenge aus der Menge aller möglichen Testfälle hat die
grösste Wahrscheinlichkeit, die meisten Fehler zu entlarven?
«Program testing can be used to show the presence of bugs,
but never show their absence!»
E. W. Dijkstra
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
56
In zwei Teilaufträge werden Sie eine Teststrategie für den Prototyp Ihres
Integrationsprojekts erstellen.
▶ Die Teststrategie ist Grundlage für die Testplanung und die Durchführung der
Tests auf allen Teststufen innerhalb des Projekts.
▶ Eine Teststrategie ist notwendig, da ein Test, der alle Komponenten des
Systems mit allen möglichen Parametern unter allen Vorbedingungen
überprüft, praktisch kaum durchführbar ist.
▶ Um hier ein realistisches Vorgehen festlegen zu können, wird innerhalb der
Testplanung anhand einer Risikoabschätzung eine Fehlerpriorisierung
vorgenommen. Dabei wird festgelegt, wie kritisch das Auftreten eines Fehlers
in einer Komponente bzw. einem Systemteil einzuschätzen ist.
▶ Wichtig in diesem Zusammenhang ist die Festlegung, wie intensiv eine
Komponente bzw. ein Systemteil getestet werden muss. Dies sollte unter
Berücksichtigung der verfügbaren Ressourcen und des Budgets geplant
werden.
Übung Teststrategie definieren
Quelle: M. Pol, T. Koomen, A. Spillner, Management und Optimierung des Testprozesses. dpunkt.Verlag
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
57
1. Zeichnen Sie für den Prototyp Ihres Integrationsprojekts ein leicht verständliches
«Big Picture» sämtlicher Komponenten und der Kommunikation zwischen diesen.
Nehmen Sie dazu die Spezifikation und die Software-Design-Dokumente zu Hilfe.
Tipp: Dieses Bild dient während den Tests als Hilfsmittel für die Kommunikation
zwischen Requirements Engineer, Tester, Entwickler und Projektleiter.
2. Machen Sie für jede Komponente und jeden Kommunikationsweg eine
Einschätzung, wie wahrscheinlich das Auftreten von Fehlern ist. Begründen Sie
Ihre Einschätzung!
3. Beurteilen Sie für Komponente und jeden Kommunikationsweg das
Schadensausmass beim Auftreten von Fehlern und erstellen Sie eine
Priorisierung mit welcher die einzelnen Komponente getestet werden müssen.
Begründen Sie Ihre Einschätzung!
Berücksichtigen Sie dabei Ihre verfügbaren Ressourcen und Ihr Zeitbudget!
Hinweis: Die Ergebnisse dieser Übung benötigen Sie als Basis für den zweiten Teil
der Übung am Ende des Kurses!
Zeitaufwand: 15 min, Präsentation:3 min
1. Teil Übung Teststrategie:
Systemübersicht und Risikoanalyse
Quelle: M. Pol, T. Koomen, A. Spillner, Management und Optimierung des Testprozesses. dpunkt.Verlag
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
58
7. Black Box Testing
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
59
▶ Der Tester kennt nur “was eine Funktion macht“
▶ Weder Code noch innerer Aufbau noch Datenstrukturen sind bekannt
▶ Ableitung der Testfälle aus Anforderungen, Spezifikation,
Benutzerhandbuch, etc.
▶ Typischerweise gegen Ende des Projekts (inkl. Abnahmetests)
eingesetzt
Definition und Funktionsweise Black Box Testing
Quelle: O.Bürgi, Systematisches Testen von Software, 2012
Black BoxTestfälle
VergleichErwartete
Resultate
Anforderungen,
Spezifikation
Erhaltene
Resultate
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
60
1. Äquivalenzklassenbildung (Equivalence Partitioning)
Äquivalenzklassen bilden. Daraus Testfälle ableiten und ein initiales
Testset bilden.
2. Grenzwertanalyse (Boundary Value Analysis)
Mit der Grenzwertanalyse die Ränder der Äquivalenzklassen
analysieren. Daraus weitere Testfälle ableiten und das Testset
ergänzen.
3. Intuitive Testfallermittlung (Error-Guessing)
Durch intuitive Testfallermittlung weitere spezielle Werte ermitteln.
Daraus weitere Testfälle ableiten und das Testset ergänzen.
Best Practice im Black Box Testing
Quelle: Uni Bremen
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
61
7.1 Äquivalenzklassenbildung
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
62
▶ Ziel:
▶ Mit einer minimalen Anzahl von Testfällen möglichst viele Fehler finden.
▶ Erhöhen der Fehlerentdeckungswahrscheinlichkeit durch die Bildung von
Äquivalenzklassen
▶ Prinzip:
▶ Eine Äquivalenzklasse ist eine Menge von Werten, von denen man
annimmt, dass das Programm identisch reagiert.
▶ Die gesamten Eingabedaten eines Programms werden in
Äquivalenzklassen unterteilt und in einer Matrix aufgelistet.
▶ Zu jeder Äquivalenzklasse wird ein Testfall definiert.
▶ Wenn anzunehmen ist, dass nicht alle Werte einer Äquivalenzklasse
identisch behandelt werden, die Äquivalenzklasse unterteilen.
▶ Die Bestimmung der Äquivalenzklassen ist hauptsächlich ein heuristischer
Prozess.
Äquivalenzklassenbildung (Equivalence Partitioning)
Myers, 1979http://www.informatik.uni-bremen.de/gdpa/methods_d/m-bbtd
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
63
▶ Grundsätzlich werden zwei Gruppen von Äquivalenzklassen unterschieden:
▶ g resp. gÄk -> gültige Äquivalenzklassen
▶ ug resp. uÄk -> ungültige Äquivalenzklassen
▶ Es gibt keine einheitliche Notation. Häufig sind:
▶ [Gültigkeit]: [untere Grenze] [log. Operator] X [log. Operator] [obere Grenze]
▶ [Gültigkeit]: X [log. Operator] [Grenze]; X [log. Operator] [Grenze]
▶ Beispiele für «Die Äquivalenzklasse ist gültig und beinhaltet alle Werte, die grösser
oder gleich 1000 und kleiner oder gleich 5000 sind»:
▶ g: 1000 <= x <=5000
▶ g: x >=1000; x <=5000
▶ g: >=1000 und <=5000
Notation für die Beschreibung von Äquivalenzklassen
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
64
Als Tester erhalten Sie den Auftrag eine Software zu testen, die basierend auf
dem Bruttowert (BW) den Nettowert (NW) berechnet. Aus der Spezifikation lesen
Sie die folgenden Anforderungen:
▶ Gültiger Wertebereich: 5.- bis 10‘000.-
▶ Beträge von 1‘000.- bis 10‘000.- erhalten 5 % Rabatt
▶ Beträge über 5‘000.- erhalten einen zusätzlichen Bonus von 200.-
▶ Es können nur ganze Zahlen eingegeben werden.
Auftrag:
1. Finden Sie mindestens 3 gültige und 3 ungültige Äquivalenzklassen
2. Definieren Sie das erwartete Verhalten (Berechnungsformel)
3. Definieren Sie je Äquivalenzklasse einen konkreten Testfall mit einem
konkreten Eingabewert und dem dazu erwarteten Resultat
Übung: Äquivalenzklassenbildung
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
65
Äquivalenzklasse
g=gültig / ug=ungültig
Erwartetes Verhalten:
Berechnungsformel
Testfall: Eingabe
Bruttowert (BW)
Erwartetes Resultat:
Ausgabe Nettowert (NW)
Testfalltabelle für Äquivalenzklassen
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
66
7.2 Grenzwertanalyse
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
67
▶ Ziel:
▶ Testfälle definieren, mit denen Fehler im Zusammenhang mit der
Behandlung der Grenzen von Wertebereichen aufgedeckt werden können.
▶ Prinzip:
▶ Die Grenzen von Wertebereichen bei der Definition von Testfällen
berücksichtigen.
▶ Ausgangspunkt sind die mittels Äquivalenzklassenbildung ermittelten
Äquivalenzklassen.
▶ Im Unterschied zur Äquivalenzklassenbildung wird kein beliebiger
Repräsentant der Klasse als Testfall ausgewählt, sondern Repräsentanten
an den Grenzen der Klassen.
▶ Die Grenzwertanalyse stellt eine Ergänzung & Präzisierung zum
Testfallentwurf gemäß Äquivalenzklassenbildung dar.
Grenzwertanalyse (Boundary Value Analysis)
Quelle: Uni Bremenhttp://www.informatik.uni-bremen.de/gdpa/methods_d/m-bbtd
Äquivalenz-
klasse alle Werte
GrenzwertanalyseGrenzwertanalyse
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
68
In der vorangehenden Übung haben Sie die Äquivalenzklassen bestimmt und
einen beliebigen Repräsentanten daraus als Testfall definiert.
Wegen der Abgrenzungsproblematik sind die Grenzen der Äquivalenzklassen
besonders fehlerträchtig (Bsp.: >; = ; >=).
Deshalb ist es besonders effizient, wenn Testfälle rund um die Grenzen der
Äquivalenzklassen ermittelt werden. Häufig kann dadurch auf zusätzliche
Testfälle innerhalb der Äquivalenzklassen verzichtet werden.
Auftrag:
1. Finden Sie je Äquivalenzklasse den minimalen und maximalen Wert als
konkreten Testfall
2. Definieren Sie wiederum das erwartete Verhalten (Berechnungsformel) und
das erwartete Resultat.
Übung: Grenzwertanalyse
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
69
Äquivalenzklasse
g=gültig / ug=ungültig
Erwartetes
Verhalten:
Berechnungsformel
Testfall: Eingabe
u: untere Grenze
o: obere Grenze
Erwartetes Resultat:
Ausgabe Nettowert (NW)
g: 5 <= x < 1’000 BW x 1u:
o:
u:
o:
g: 1’000 <= x <=5’000 BW x 0.95u:
o:
u:
o:
g: 5’000 < x <=10’000 BW x 0.95 – 200.-u:
o:
u:
o:
ug: x < 5 Fehlermeldungo:
u:
o:
u:
ug: 10’000 < x Fehlermeldungo:
u:
o:
u:
ug: x ist keine ZahlEingabe nicht
möglich---------------- -----------------
Testfalltabelle für Grenzwerte
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
70
▶ Kombinationen von Eingabebedingungen können mit Äquivalenzklassen nicht
übersichtlich abgebildet werden
▶ Grenzwertanalyse ist ungeeignet für Boolesche Parameter
▶ Das Finden aller relevanten Äquivalenzklassen und Grenzwerte ist schwierig
Fazit
▶ Äquivalenzklassenbildung und Grenzwertanalyse können keine vollkommene
Menge von Testfälle liefern
▶ Ein Rezept für die Auswahl von Testdaten ist schwierig anzugeben. Kreativität
zur Findung erfolgreicher Testdaten nötig
▶ Kombination mit weiteren Methoden sinnvoll:
▶ Error Guessing
▶ Allenfalls Verwendung von Entscheidungstabellen,
Ursachen-Wirkungs-Graphen, Entscheidungsbäumen
Limitationen von Äquivalenzklassenbildung und
Grenzwertanalysen
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
71
7.3 Intuitive Testfallermittlung
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
72
▶ Ziel:
▶ Die systematisch ermittelten Testfälle qualitativ verbessern durch
das Ermitteln ergänzender Testfälle.
▶ Prinzip:
▶ Grundlage für diesen methodischen Ansatz ist die intuitive
Fähigkeit und Erfahrung von Menschen, Testfälle nach erwarteten
Fehlern auszuwählen.
▶ Nach Analyse der Anforderungen und der systematisch
ermittelten Testfälle wird eine Liste möglicher weiterer
fehlerverdächtiger Situationen und immer wieder auftretender
Standardfehler erstellt.
▶ Anhand dieser Liste definiert man die zusätzlichen Testfälle.
▶ Achtung: Insbesondere implizite Nichtfunktionale Anforderungen
berücksichtigen!
Intuitive Testfallermittlung (Error-Guessing)
Quelle: Uni Bremenhttp://www.informatik.uni-bremen.de/gdpa/methods_d/m-bbtd
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
73
Sie haben nun für die Äquivalenzklassen und die Grenzwerte Testfälle bestimmt.
Aus Ihrer Erfahrung wissen Sie, dass es aber noch weitere kritische Bereiche gibt,
an denen sich gerne Fehler verstecken.
Auftrag:
1. Ermitteln Sie intuitiv weitere fehlerverdächtige Situationen bzw. immer wieder
auftretende Standardfehler.
Notieren Sie stichwortartig, warum Sie diese Situationen als fehlerträchtig
einstufen.
2. Leiten Sie daraus zusätzliche Testfälle ab.
3. Definieren Sie wiederum das erwartete Verhalten (Berechnungsformel) und
das erwartete Resultat.
Übung: Error Guessing
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
74
Fehlerverdächtige
Situation
Begründung, mögliches
Fehlverhalten
Testfall: Eingabe Erwartetes
Verhalten /
Resultat
Testfalltabelle für intuitive Testfallermittlung
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
75
7.4 Integrationsübung Black Box Testing
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
76
Übungsvorbereitung:
▶ In der folgenden Übung muss ein Windows-Programm getestet werden.
▶ Falls Sie über keinen Windows-Laptop verfügen, schliessen Sie sich einer Gruppe an, welche über
ein entsprechendes Gerät verfügt.
Ausgangslage:
▶ Sie erhalten den Auftrag eine Software zur Flächenberechnung beliebiger Dreiecke zu testen.
▶ Die zu prüfende Software «Triangle.exe» ist abgelegt auf Moodle
▶ Der Source Code liegt nicht vor, jedoch die folgende Spezifikation:
Übung Blackbox Testing: Dreiecksberechnung
Quelle: O.Bürgi, Systematisches Testen von Software, 2012
Spezifikation Das Programm soll die Fläche eines Dreiecks auf 4 Stellen
nach dem Komma berechnen.
Dazu sollen die drei Seiten vom Benutzer eingegeben werden
müssen.
Weiter prüft das Programm, ob es
sich bei den Eingaben um ein
gültiges Dreieck handelt. Falls
ja, wird die Dreiecks-Fläche
ausgegeben, falls nein ein
entsprechender Fehlertext
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
77
Ausgangslage:
▶ Es existieren bereits viele ähnliche Tools zur Dreiecks-Berechnung. Im Internet
finden Sie sogar Tools zur Online-Berechnung z.B.:
▶ http://rechneronline.de/pi/dreieck.php
▶ http://www.mathepower.com/dreieck.php
▶ Es wäre also naheliegend, einfach mal auszuprobieren, ob sich das zu testende
Programm gleich verhält wie diese Tools
Auftrag:
▶ Arbeiten Sie gemeinsam mit Ihrem Pultnachbarn.
▶ Versuchen Sie durch zufälliges Eingeben von Werten Fehler im Programm zu
finden.
▶ Wie viele Fehler haben Sie gefunden?
▶ Wie viele Berechnungen mussten Sie dazu ausführen?
▶ Können Sie die Fehler reproduzieren?
Zeitaufwand: ca. 3-5 min
Auftrag: Experimentelles Testen
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
78
▶ Durch das experimentelle Testen haben Sie den einen oder anderen
Fehler gefunden.
▶ Aber das Verhältnis «Anzahl ausgeführte Testfälle pro gefundenen
Fehler» ist ungünstig, was vor allem bei wiederholten Regressionstests
viel Zeit kostet.
▶ Ausserdem können Sie keine Aussage zur Testabdeckung machen und
können nicht beurteilen, wann genügend getestet ist.
▶ Mit einem systematischen Vorgehen können Sie die Effektivität der Tests
verbessern
Experimentelles Testen: Lessons learned
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
79
▶ Zum Spezifizieren effektiver Testfälle benötigen sie geeignete Datenquellen. Als Testorakel
kommen nebst der Spezifikation auch Formeln zur Dreiecksberechnung in Frage. Zum Beispiel
die Formel des Heron. Diese finden Sie auf Moodle unter:
«Heronsche_Formel.pdf» resp. «heron.xls»
▶ Das Finden von Äquivalenzklassen ist ein kreativer Prozess. Im Falle der Dreiecksberechnung
hilft ein Blick auf die unterschiedlichen Dreiecksformen (und deren unterschiedliche
Berechnungsformeln)
Auftrag:
▶ Definieren Sie durch Äquivalenzklassenbildung, Grenzwertanalyse und Errorguessing
systematisch Testfälle. Ziel: Mit möglichst wenig Testfällen möglichst viele Fehler finden
▶ Führen Sie die Tests aus und protokollieren Sie die Ergebnisse in einer Excel-Tabelle.
▶ Wie viele Fehler haben Sie gefunden?
Zeitaufwand: ca. 10 - 15min, anschliessend Besprechung im Plenum
Auftrag: Systematisches Testen
a a
a
Gleichseitiges
Dreieck
a a
b
Gleichschenkliges
spitzwinkliges
Dreieck
a a
b
Gleichschenkliges
Stumpfwinkliges
Dreieck
a b
c
Rechtwinkliges
Dreieck
a b
c
Unregelmässiges
Dreieck
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
80
8. White Box Testing
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
81
▶ Beim White Box Testing liegt der Source Code vor.
▶ Der Source Code wird in einen Kontrollflussgraphen transferiert
anhand dessen Testfälle zum Erreichen der verlangten
Überdeckungsgrade definiert werden.
1. Anweisungsüberdeckung (Knoten)
▶ Alle Anweisungen sollen durchlaufen werden.
2. Zweigüberdeckung (Kanten)
▶ Alle Zweige (Kontrollfüsse) sollen durchlaufen werden.
3. Bedingungsüberdeckung
▶ Einfache Bedingungsüberdeckung: Jede atomare
Teilbedingung soll einmal den Wert true und einmal den
Wert false annehmen
▶ (Minimale) Merfachbedingungsüberdeckung: Alle
Kombinationen von Teilbedingungen sollen durchlaufen
werden
▶ Pfadüberdeckung: Verschiedene Kombinationen von
Programmteilen (Pfaden) sollen durchlaufen werden
Überdeckungsgrade
Quelle: A.Spillner, T.Linz, Basiswissen Softwaretesten, dpunkt Verlag
if
do
while
end if
Kontrollflussgraph
Anweisung = Knoten
Kontrollfluss= Kante
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
82
e
g
a
Anweisungsüberdeckung
Quelle: A.Spillner, T.Linz, Basiswissen Softwaretesten, dpunkt Verlag
if
if
end if
end if
do
while
b
f
d
c i k
Zum Erreichen der
Anweisungsüberdeckung müssen
sämtliche Anweisungen (Knoten)
mindestens einmal
durchlaufen werden.
Frage:
Wie mancher Testfall ist nötig für
eine vollständige
Anweisungsüberdeckung?
Geben Sie an, welche Kanten dazu
mindesten durchlaufen werden
müssen!
h
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
83
e
g
a
Zweigüberdeckung
Quelle: A.Spillner, T.Linz, Basiswissen Softwaretesten, dpunkt Verlag
if
if
end if
end if
do
while
b
f
d
c i k
Zum Erreichen der
Zweigüberdeckung müssen
sämtliche Kanten (Kontrollfüsse)
mindestens einmal
durchlaufen werden.
Frage:
Wie mancher Testfall ist nötig für
eine vollständige
Zweigüberdeckung?
Welche Kanten müssen dazu
jeweils durchlaufen werden?
h
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
84
Bedingungsüberdeckung
Vorbereitung: Atomare Teilbedingungen schaffen
Quelle: A.Spillner, T.Linz, Basiswissen Softwaretesten, dpunkt Verlag
if(a>1 or b>1)
end if
end if
Eine atomare Teilbedingung ist eine
Bedingung, die keine logischen
Operatoren wie AND, OR, NOT
sondern höchstens Relationssymbole
wie > oder = enthält
Vorbereitung:
Lösen Sie im nebenstehenden
Kontrollflussgraphen die
Bedingungen in den Knoten in
atomare Teilbedingungen auf.
Zeichnen Sie einen neuen
Kontrollflussgraphen mit Knoten
aus atomaren Teilbedingungen!
if(a=2 and b=2)
then else
then else
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
85
Bedingungsüberdeckung
Vorbereitung : Atomare Teilbedingungen schaffen
Quelle: A.Spillner, T.Linz, Basiswissen Softwaretesten, dpunkt Verlag
if(a>1)
end if
end if
Ergebnis: Jede Bedingung wurde in
seine atomaren Teilbedingungen aufgelöst
if(a=2)
if(b>1)
then
then
else
else
if(b=2)
then else
then
if(a>1 or b>1)
if(a=2 and b=2)
else
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
86
f
a
Einfache Bedingungsüberdeckung
Quelle: A.Spillner, T.Linz, Basiswissen Softwaretesten, dpunkt Verlag
if(a>1)
end if
end ife
h
if(a=2)
if(b>1)
then
then
else
else
if(b=2)
then else
then
Zum Erreichen der einfachen
Bedingungsüberdeckung muss jede
Teilbedingung einmal den Wert true
und einmal den Wert false
annehmen.
Frage:
Wie mancher Testfall ist nötig für
eine einfache
Bedingungsüberdeckung?
Definieren Sie für jeden Testfall
konkrete Werte (für die Variablen
a und b) und listen Sie auf,
welche Kanten durchlaufen
werden!
b
c
d
g
l
i
k
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
87
f
a
Mehrfachbedingungsüberdeckung
Quelle: A.Spillner, T.Linz, Basiswissen Softwaretesten, dpunkt Verlag
1
3
if(a>1)
end if
end ife
h
if(a=2) 2
if(b>1)
then
then
else
else
4if(b=2)
then else
then
Für eine (vollständige) Mehrfachbedingungs-überdeckung müssen alle Kombinationen von Teilbedingung durchlaufen werden.
Frage: Wie mancher Testfall wäre
(theoretisch) nötig zum Erreichen einer vollständigen Mehrfachbedingungs-überdeckung?
b
c
d
g
l
i
k
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
88
Minimale Mehrfachbedingungsüberdeckung
Quelle: A.Spillner, T.Linz, Basiswissen Softwaretesten, dpunkt Verlag
Bei der minimalen
Mehrfachbedingungsüberdeckung müssen
nur diejenigen Kombinationen
berücksichtigt werden, bei denen die
Änderung des Wahrheitswertes einer
atomaren Teilbedingung den
Wahrheitswert der logischen Bedingung
ändern kann.
Aufgabe:
Listen Sie für die Bedingung
if(a>1 or b>1) alle möglichen
Kombinationen von atomaren
Teilbedingungen auf indem Sie für die
Variablen a und b konkrete Werte
einsetzen.
Auf welche kann für die minimale
Mehrfachbedingungsüberdeckung
verzichtet werden? Begründen Sie!
f
a
1
3
if(a>1)
end if
end ife
h
if(a=2) 2
if(b>1)
then
then
else
else
4if(b=2)
then else
then
b
c
d
g
l
i
k
if(a>1 or b>1)
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
89
e
g
a
Pfadüberdeckung
Quelle: A.Spillner, T.Linz, Basiswissen Softwaretesten, dpunkt Verlag
if
if
end if
end if
do
while
b
f
d
c i k
Mit den bisherigen Betrachtungen
werden Schleifen bzw. Wiederholungen
nicht angemessen berücksichtigt.
Hier hilft die Pfadüberdeckung. Ein Pfad
beschreibt eine mögliche Abfolge von
einzelnen Programmteilen in einem
Programmstück.
Aufgabe :
Beschreiben Sie vier verschiedene
Abfolgemöglichkeiten zum
Durchlaufen der nebenstehenden do
while Schlaufe. Berücksichtigen Sie
auch Extremfälle!
Geben Sie an, welche Kanten dazu
mindesten durchlaufen werden
müssen!
h
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
90
e
g
a
Pfadüberdeckung
Quelle: A.Spillner, T.Linz, Basiswissen Softwaretesten, dpunkt Verlag
if
if
end if
end if
do
while
b
f
d
c i k
Lösung:
f, g, h
(i wird nie durchlaufen)
f, g, i, h
(i wird genau 1 mal durchlaufen)
f, g, i, g, i, g, i, g, i, g, i, g, h
(i wird n mal durchlaufen)
f, g, i, g, i, g, i, g, i, g, i, g, …
(Schlaufe wird nie verlassen)
h
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
91
9 Zustandsbezogene Tests
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
92
▶ Bei vielen Systemen hat nebst den unmittelbaren Eingabewerten (Aktion) auch
der bisherige Ablauf des Systems, also sein Zustand Einfluss auf die
Berechnung der Ausgaben bzw. auf das Systemverhalten.
▶ Für solche zustandsbezogene Tests sind Vorbedingungen zu erfüllen und die
Einhaltung von Nachbedingungen zu überprüfen.
▶ Zustandsbezogene Tests können sowohl im White Box Testing als auch im
Black Box Testing eingesetzt werden.
Zustandsbezogene Tests
Quelle: A.Spillner, T.Linz, Basiswissen Softwaretesten, dpunkt Verlag
Zustand 1 Zustand 2 Zustand 4
Zustand 3
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
93
Ausgangslage & Aufgabe:
▶ Sie haben den Auftrag erhalten, Blackbox Tests für einen Stack zu schreiben.
▶ In der API-Dokumentation finden Sie die obenstehende Grafik und den
Hinweis, dass der Stack nach dem LIFO-Prinzip arbeitet und nur Strings
akzeptiert.
▶ Definieren Sie Testfälle, indem Sie Vorbedingungen, Aktionen, Sollreaktion und
Nachbedingung festlegen.
▶ Versuchen sie die Anzahl Testfälle klein zu halten, indem Sie
Äquivalenzklassen bilden und deren Grenzwerte testen
Übung: Zustandsbezogene Tests
Quelle: A.Spillner, T.Linz, Basiswissen Softwaretesten, dpunkt Verlag
leer gefüllt voll
new(size) push()[size = MAX-1]
pop() [size = 1] pop()
push() [size < MAX-1]
push()
pop() [size > 1]
finalize()
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
94
Testfalltabelle für zustandsbezogene Tests
Vorbedingung / Zustand Aktion / EingabeSollreaktion
(erwartetes Verhalten)Nachbedingung / Zustand
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
95
10 Entscheidungstabellentechnik /
Ursachen-Wirkungs-Analyse
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
96
▶ Entscheidungstabellen werden direkt erstellt, aus Entscheidungsbäumen
abgeleitet oder aus Ursache-Wirkungs-Graphen ermittelt
▶ Dazu werden von jeder Teilspezifikation Ursachen und Wirkungen
identifiziert
▶ Eine Ursache ist eine einzelne Eingabebedingung oder eine Äquivalenzklasse
von Eingabebedingungen
▶ Eine Wirkung ist eine Ausgabebedingung oder eine Systemtransformation.
▶ Entscheidungstabellentechnik und Ursachen-Wirkungs-Analyse können sowohl
im White Box Testing als auch im Black Box Testing zum Ermitteln von
Testfällen eingesetzt werden.
Entscheidungstabellentechnik /
Ursachen-Wirkungs-Analyse
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
97
▶ In der Entscheidungstabelle werden Variablen mit ihren möglichen Belegungen
(Ursachen) gelistet sowie die jeweils erwartete Entscheidung (Wirkung)
▶ Jede Tabellenspalte der Entscheidungstabelle entspricht einem möglichen
Testfall
▶ Beispiel einer vollständige Entscheidungstabelle für 3 Ursachen.
▶ Bei 3 Ursachen gibt es bereits 8 mögliche Testfälle (2n)
Heuristik zur Auswahl nötig!
Entscheidungstabelle
Quelle: Peter Liggesmeyer, Analysieren und Verifizieren von Software
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
98
▶ Testfälle aus dem Entscheidungsbaum
Entscheidungsbaum
Quelle: Peter Liggesmeyer, Analysieren und Verifizieren von Software
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
99
▶ Testfälle aus dem Ursache-Wirkungs-Graph
Ursache-Wirkungs-Graph
Quelle: Peter Liggesmeyer, Analysieren und Verifizieren von Software
Notation:
Identität
Negation∼
Und
˄
Oder
˅
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
100
11. Testpraktiken & Testtools
Eine Zusammenfassung aus Trends & Benchmarks 2016
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
101
▶ Nebst Unit Testing und
Continuous Integration
werden klare
Akzeptanzkriterien und
Definition of Done als
wichtigste QS-Praktiken
beurteilt.
▶ Eine weitere wichtige
Praktik sind das
interdisziplinäre und
explorative Testen und
die Abnahmetests am
Ende jedes Sprints.
▶ Das Automatisieren der
GUI- und Schnittstellen-
tests, Pair Programming
und testgetribene
Entwicklungsweisen
werden als weitere
wichtige Praktiken
genannt.
Agile Test / QS Praktiken
Quelle: swissQ, Trends & Benchmarks 2016
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
102
▶ Die Verbreitung von Jira hat
sich gegenüber dem Vorjahr
auf einem hohen Niveau
stabilisiert, während HP ALM
ein paar Prozentpunkte
verloren hat und mit MS
Office gleichauf ist.
▶ Dahinter konnte sich
weiterhin kein klarer Favorit
etablieren.
Testmanagement Tools
Quelle: swissQ, Trends & Benchmarks 2016
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
103
▶ Der Markt der Testautomatisierungs-Tools ist und bleibt recht stark fragmentiert.
Es kommt eine grosse Zahl verschiedener Tools zum Einsatz, darunter viele
Eigenentwicklungen.
▶ Im Web-Bereich hat Selenium (http://docs.seleniumhq.org/) stark zugelegt.
Testautomatisierungs-Tools
Quelle: swissQ, Trends & Benchmarks 2016
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
104
▶ Der Anteil an automatisierten Systemtests hat sich in den letzten Jahren
kontinuierlich gesteigert.
▶ Dennoch liegt der Automatisierungsgrad nur in Ausnahmefällen bei über 50%
Automatisierungsgrad
Quelle: swissQ, Trends & Benchmarks 2016
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
105
▶ Die Mehrheit geht von Kosteneinsparungen bis 20% aus – oder kann keine
Aussagen dazu machen. Die Werte haben sich über die Jahre kaum verändert.
▶ Die Kostenersparnis ist aber nicht Treiber für die Testautomatisierung sondern der
Bedarf nach kürzeren Entwicklungsiterationen und häufigerem Deployment.
Kosteneinsparung bei Testautomatisierung
Quelle: swissQ, Trends & Benchmarks 2016
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
106
▶ LoadRunner von HP ist das
meist genutzte
Performance-Test-
Werkzeug.
▶ Andererseits arbeiten
jedoch nach wie vor viele
Unternehmen mit
Eigenentwicklungen.
▶ Als wichtigste
Erfolgsfaktoren Last &
Performance Testing
gelten realistische
Szenarien und eine
produktionsnahe
Testumgebung
Last & Performance Test Tools
Quelle: swissQ, Trends & Benchmarks 2016
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
107
12. Testendkriterien
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
108
▶ Der Projektleiter benötigt eine befriedigende Antwort auf die Frage:
▶ Wann kann man (oder soll man) mit Testen aufhören?
▶ Allgemeine Antwort:
▶ Wenn das erforderliche Mass an Vertrauen in die Software herbeigeführt
ist!
▶ Dieser Grad des Vertrauens – die Testendkriterien – müssen naturgemäss vor
dem Beginn des Tests festgelegt werden. Sie dienen als Planungsgrundlage.
▶ Nicht alle Testendkriterien eignen sich gleichermassen, um das erforderliche
Mass an Vertrauen herbeizuführen.
Kriterien für die Beendigung der Tests
Quelle: O.Bürgi, Systematisches Testen von Software, 2012
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
109
Typischer Verlauf der Fehlerentdeckungskosten
Quelle: O.Bürgi, Systematisches Testen von Software, 2012
Zeit
Kosten Kostengrenze
(pro gefundenen
Fehler)T
estbeginn
Testende
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
110
▶ Zeit als Beendigungskriterium
▶ Der Test wird nach x Wochen beendet (?!)
▶ Der Test wird mit Erreichend des entsprechenden Meilensteins beendet (?!)
▶ Fehlerfindungsrate als Beendigungskriterium
▶ Der Test wird beendet, wenn während x Tagen kein schwerwiegender
Fehler mehr gefunden wurde.
▶ Überdeckungsgrad als Beendigungskriterium
▶ X% der Äquivalenzklassen / Grenzwerte wurden getestet
▶ X% der Anweisungen, Zweige wurden durchlaufen
▶ Jeder Zustand wurde mindestens einmal erreicht
▶ Jeder Zustandsübergang wurde mindestens einmal ausgeführt
▶ Funktionsüberdeckung: Jede Funktion wurde getestet (Testfallmatrix)
▶ Anforderungsüberdeckung: Jede Anforderung wurde durch mindestens
einen Testfall geprüft (Testfallmatrix).
Testendkriterien
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
111
▶ Ziel:
▶ Testfälle identifizieren, mit denen nachgewiesen werden kann, dass die
jeweilige Funktion vorhanden und auch ausführbar ist.
▶ Hierbei wird der Testfall auf das Normalverhalten und das
Ausnahmeverhalten des Prüfgegenstandes ausgerichtet.
▶ Prinzip:
▶ Anhand der definierten Anforderungen werden die zu testenden
Funktionen identifiziert.
▶ Für die identifizierten Funktionen werden Testfälle definiert.
▶ Mit Hilfe einer Testfallmatrix wird überprüft, ob Funktionen durch
mehrere Testfälle abgedeckt sind.
▶ Zur Verbesserung der Testwirtschaftlichkeit sollten redundante Testfälle
gelöscht werden.
Funktionsabdeckung als Testendkriterium
Quelle: Uni Bremenhttp://www.informatik.uni-bremen.de/gdpa/methods_d/m-bbtd
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
112
Beispiel Testfallmatrix
Quelle: O.Bürgi, Systematisches Testen von Software, 2012
Testfall
Anforderung (SRS) TF
-101
TF
-102
TF
-103
TF
-104
TF
-105
TF
-106
TF
-107
TF
-108
TF
-109
TF
-201
TF
-202
TF
-203
TF
-204
TF
-205
TF
-301
Tf-
302
An
zah
l
An
ford
eru
ng
en
:
AG1-1 x x 2
AG1-2 0
AG1-3 x x 2
AG1-4 0
AG1-5 0
AG1-6 0
AF2-1 x x x 3
AF2-2 x x x x x 5
AF2-3 x x x x 4
AF2-4 x x x x 4
AF2-5 x x x 3
AF3-1 x x 2
AF3-2 x x 2
AF3-3 x 1
AF3-4 x 1
Anzahl Testfälle: 7 7 0 0 0 3 3 3 0 4 0 0 0 2 0 0Anzahl Anforderungen
An
zah
l
Test
fälle
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
113
▶ Im ersten Teil der Übung haben Sie definiert, welche Objekte warum getestet
werden müssen.
▶ Im zweiten Teil geht es darum, wie und in welcher Reihenfolge diese Objekte
getestet werden.
▶ Ebenso müssen die Kriterien zur Beendigung der Tests definiert werden:
1. Bestimmen Sie welche Testmethoden Sie auf welchen Stufen einsetzen
wollen und wie diese Testmethoden zusammenspielen sollen!
2. Definieren Sie unter Berücksichtigung der vorangegangenen
Priorisierung, in welcher Reihenfolge die Testmethoden auf die einzelnen
Artefakte (Testobjekte) anzuwenden sind!
3. Legen Sie die zu erreichenden Überdeckungsgrade resp. die Kriterien zur
Beendigung der Tests für jede Testmethode resp. Jedes Artefakt fest.
4. Machen Sie einen Vorschlag für die einzusetzenden Testwerkzeuge!
Zeitaufwand: 15 min, Präsentation:3 min
2. Teil Übung Teststrategie:
Testmethodik und Testendkriterien festlegen
Quelle: M. Pol, T. Koomen, A. Spillner, Management und Optimierung des Testprozesses. dpunkt.Verlag