5. Software-Testing allgemein
Wann testen?
Was testen?
Warum testen?
Auf welcher Grundlage testen?
Test-Dimensionen:
Test-Methodik
Test Types
Test Levels
Test Techniques
Test Tools
Markus Wichmann
6. Software-Testing allgemein:
Wann testen? 1/4
Wann testen?
Was testen?
Warum testen?
Auf welcher Grundlage testen?
Test-Dimensionen:
Test-Methodik
Test Types
Test Levels
Test Techniques
Test Tools
Markus Wichmann
7. Software-Testing allgemein:
Wann testen? 2/4
Wann testen? Früh. Oft.
Was testen?
Warum testen?
Auf welcher Grundlage testen?
Test-Dimensionen:
Test-Methodik
Test Types
Test Levels
Test Techniques
Test Tools
Markus Wichmann
8. Software-Testing allgemein:
Wann testen? 3/4
Wann testen? Früh. Oft. Noch was?
Allgemeines Vorgehen:
1. Finden von Test-Fällen
2. Konstruieren von Tests (und Testdaten)
3. Durchführen von Tests
4. Evaluation, Aufbewahren von Ergebnissen
Markus Wichmann
9. Software-Testing allgemein:
Wann testen? 4/4
Wann testen? Und wie eigentlich?
Allgemeine Anforderungen an Tests:
1. objektiv: nur Erfüllung von Anforderungen zählt (PASS, FAIL)
2. systematisch: Festlegung Test-Ziele vor Test-
Implementierung
3. „vollständig“: In sich schlüssige Test-Ergebnisse erreicht
4. integral: Beurteilungskriterien der SW an sich (nicht die der Tests)
liegen vor Implementierung der Software vor
Markus Wichmann
10. Software-Testing allgemein:
Was testen? 1/3
Wann testen? FRÜH!
Was testen?
Warum testen?
Auf welcher Grundlage testen?
Test-Dimensionen:
Test-Methodik
Test Types
Test Levels
Test Techniques
Test Tools
Markus Wichmann
11. Software-Testing allgemein:
Was testen? 2/3
1. Funktionale Anforderungen, Beispiele:
○ Produkt soll Zahl von Flows in Zeitraum x in Liniengrafik anzeigen
○ Produkt soll unnötige Daten des letzten Tags von Platte löschen
Markus Wichmann
12. Software-Testing allgemein:
Was testen? 3/3
1. Funktionale Anforderungen, Beispiele:
○ Produkt soll Zahl von Flows in Zeitraum x in Liniengrafik anzeigen
○ Produkt soll unnötige Daten des letzten Tags von Platte löschen
2. Nicht-funktionale (=Qualitäts)Anforderungen
○ Zuverlässigkeit
○ Wartbarkeit
○ Korrektheit angezeigter Ergebnisse
○ Benutzbarkeit
○ Leistung
○ Sicherheitsanforderungen
○ Skalierbarkeit
○ (weitere)
Markus Wichmann
13. Software-Testing allgemein:
Warum testen? 1/2
Wann testen? FRÜH!
Was testen? Anforderungen.
Warum testen?
Auf welcher Grundlage testen?
Test-Dimensionen:
Test-Methodik
Test Types
Test Levels
Test Techniques
Test Tools
Markus Wichmann
14. Software-Testing allgemein:
Warum testen? 2/2
○ Mängel finden
○ Vertrauen in Qualität finden
○ „Deployment-Readiness“ beurteilen
○ Info für Entscheidungsfindung geben
○ Mängel verhindern
○ Qualität messen
Markus Wichmann
15. Software-Testing allgemein:
Auf welcher Grundlage testen? 1/2
Wann testen? FRÜH!
Was testen? Anforderungen.
Warum testen? Aussagen über Systemreife.
Auf welcher Grundlage testen?
Test-Dimensionen:
Test-Methodik
Test Types
Test Levels
Test Techniques
Test Tools
Markus Wichmann
16. Software-Testing allgemein:
Auf welcher Grundlage testen? 2/2
Auf Grundlage der Anforderungen!
● Funktionale Anforderungen, z.B. an
○ ganzen Geschäftsablauf, Funktion eines Formulars,
Konfigurationsdaten, Anwenderführung, Funktion
der Infrastruktur, Vollständigkeit der
Datenbankstruktur, einzelne Berechnungen, ganze
Module, einzelne Klassen eines Modul, einzelne
Funktionen einer Klasse
● Nicht-funktionale
○ Siehe Software-Testing allgemein: Was testen? 3/3 Markus Wichmann
17. Software-Testing allgemein:
Test-Dimensionen
Wann testen? FRÜH!
Was testen? Anforderungen.
Warum testen? Aussagen über Systemreife.
Auf welcher Grundlage testen? Anforderungen.
Test-Dimensionen:
Test-Methodik
Test Types
Test Levels
Test Techniques
Test Tools
Markus Wichmann
18. Software-Testing allgemein:
Test-Dimensionen
Wann testen? FRÜH!
Was testen? Anforderungen.
Warum testen? Aussagen über Systemreife.
Auf welcher Grundlage testen? Anforderungen.
Test-Dimensionen:
Test-Methodik
Test Types
Test Levels
Test Techniques
Test Tools
Markus Wichmann
19. Software-Testing allgemein:
Test-Dimensionen: Test-Methodik
Black-Box-Tests
○ Herleitung von Tests aus Spezifikation
○ ergebnisorientiert aus Anwendersicht
○ testen nicht die konkrete Implementierung
○ ohne Blick in Quellcode
○ oft eher „globale“ Tests
White-Box-Tests
○ Herleitung von Tests aus Quellcode
○ testen innere Funktionsweise der Software
○ mit Blick in Quellcode
○ oft eher „fokale“ Tests
Markus Wichmann
20. Software-Testing allgemein:
Test-Dimensionen
Wann testen? FRÜH!
Was testen? Anforderungen.
Warum testen? Aussagen über Systemreife.
Auf welcher Grundlage testen? Anforderungen.
Test-Dimensionen:
Test-Methodik
Test Types
Test Levels
Test Techniques
Test Tools
Markus Wichmann
22. Software-Testing allgemein:
Test-Dimensionen: Test Types 2/5
Funktionale Tests
○ Frage: „Was tut das System?“
○ Test Levels: alle (dazu später)
○ Methodik: Black-Box
Markus Wichmann
23. Software-Testing allgemein:
Test-Dimensionen: Test Types 3/5
Nicht-funktionale Tests
○ Frage: „Wie tut das System, was es nunmal tut?“
○ Test Levels: alle (dazu später)
○ Methodik: Black-Box
Markus Wichmann
25. Software-Testing allgemein:
Test-Dimensionen: Test Types 5/5
Regression-Tests
○ Wiederholtes Testen bereits getesteter Dinge
nach erneuten Änderungen
○ Tests müssen vor und nach Änderungen gleich sein
○ Test Levels: alle (dazu später)
○ beinhalten(!)
○ funktionale
○ nicht-funktionale und
○ Struktur-Tests
Markus Wichmann
26. Software-Testing allgemein:
Test-Dimensionen
Wann testen? FRÜH!
Was testen? Anforderungen.
Warum testen? Aussagen über Systemreife.
Auf welcher Grundlage testen? Anforderungen.
Test-Dimensionen:
Test-Methodik
Test Types
Test Levels
Test Techniques
Test Tools
Markus Wichmann
28. Software-Testing allgemein:
Test-Dimensionen: Test Levels 2/6
Component Tests
Subjekte: Unit, Methode, Class, Perl-Modul o.ä.
Methodik: White-Box, oft test-first
Types:
funktional
nicht-funktional (Memory Leaks, Decision Coverage)
Grundlagen:
Component Requirements
SW-Design
Source Code
Markus Wichmann
29. Software-Testing allgemein:
Test-Dimensionen: Test Levels 3/6
Integration Tests:
Zweck: Test von Zusammenspiel von Components
Subjekte:
Subsysteme, DB, Infrastruktur, Schnittstellen,
Konfig-Daten
Grundlagen:
SW-Design
Architektur
Arbeitsabläufe
Anwendungsfälle
Markus Wichmann
30. Software-Testing allgemein:
Test-Dimensionen: Test Levels 4/6
System Tests
Subjekt: System als Ganzes, vollständig
Methodik:
White-Box (z.B. Menüstruktur, Navigation)
Black-Box (z.B. Entscheidungsbäume, „Geschäftsregeln“)
Grundlagen:
Anforderungen (siehe Software-Testing allgemein: Auf welcher Grundlage testen? 2/2)
Anwendungsfälle
Risikoanalysen
Markus Wichmann
31. Software-Testing allgemein:
Test-Dimensionen: Test Levels 5/6
Smoke Tests
Subjekte: System als Ganzes
Umfang: sehr eingeschränkt
Zweck:
Finden von Show-Stoppern vor eigentlichen Tests,
vergleichbar mit kurzem Einstecken eines el. Geräts
Methodik:
Black-Box (z.B. Entscheidungsbäume, „Geschäftsregeln“)
Grundlagen:
Nur grundlegendste Anforderungen („Zuckt da was?“)
Markus Wichmann
32. Software-Testing allgemein:
Test-Dimensionen: Test Levels 6/6
Acceptance Tests
Subjekte: System als Ganzes
Umfang: nach Risikoabwägung
Methodik: Black-Box
Grundlagen:
Anforderungen (siehe Software-Testing allgemein: Auf welcher Grundlage testen? 2/2)
Abläufe aus Anwendersicht („Business Processes“)
Geplante Anwendungsfälle
Geplanter Gesamtablauf bei Verwendung der SW
Risikoanalysen
Markus Wichmann
33. Software-Testing allgemein:
Test-Dimensionen
Wann testen? FRÜH!
Was testen? Anforderungen.
Warum testen? Aussagen über Systemreife.
Auf welcher Grundlage testen? Anforderungen.
Test-Dimensionen:
Test-Methodik
Test Types
Test Levels
Test Techniques
Test Tools
Markus Wichmann
34. Software-Testing allgemein:
Test-Dimensionen: Test Techniques 1/3
Static Techniques (=Code-Untersuchung ohne dessen Ausführung)
Test Design Techniques (aka Dynamic Techniques)
Markus Wichmann
35. Software-Testing allgemein:
Test-Dimensionen: Test Techniques 2/3
Static Techniques (=Code-Untersuchung ohne dessen Ausführung)
Code Review (Informal, Walk-Through, Tech. Review, Inspection)
Automatisierte Code-Analyse
Mängel vor der Ausführung finden: Undefinierte und unbenutzte
Variablen, Endlosschleifen, Syntax-Fehler, toter Code, Verletzung von
Coding Standards
Abhängigkeiten aufdecken
Markus Wichmann
36. Software-Testing allgemein:
Test-Dimensionen: Test Techniques 3/3
Test Design Techniques (aka Dynamic Techniques)
Spec-basierte, für
Randwerte
Entscheidungsbäume
Zustands-Übergänge
Struktur-basierte, für
Code Coverage (Statement Coverage, Decision Coverage)
Erfahrungs-basierte
Exploratives Testen („Rumklicken“)
Gezieltes Provozieren von Fehlern (Tester kennt spezifische
(ehemalige) Schwachstellen der Anwendung)
Erraten von Fehlern (Tester kennt Schwachstellen von SW allgemein)
Markus Wichmann
37. Software-Testing allgemein:
Test-Dimensionen
Wann testen? FRÜH!
Was testen? Anforderungen.
Warum testen? Aussagen über Systemreife.
Auf welcher Grundlage testen? Anforderungen.
Test-Dimensionen:
Test-Methodik
Test Types
Test Levels
Test Techniques
Test Tools
Markus Wichmann
38. Software-Testing allgemein:
Test-Dimensionen: Test Tools
Static Testing Tools
Review Tools
Static Analysis Tools
Modeling Tools
Test Execution Tools
Unit Test Frameworks
Test Comparators
Coverage Measurement Tools
Security Test Tools
Performance Testing Tools
Load Test, Monitoring, usw.
Markus Wichmann
40. Web-UI-Testing: Merkmale zur
Unterscheidung von Test-Frameworks
Dutzende Frameworks zur Verfügung
Untscheiden sich stark z.B. bei
Zweck
Aussagefähigkeit in Bezug auf Kunden-Anforderungen
Komplexität beim Setup, auch Setup von Infrastruktur
Komplexität beim Schreiben der Tests
Zeitdauer des Testlaufs
Continuous-Integration-Fähigkeit (z.B. mit Jenkins, Hudson, etc.)
Reifegrad des Test-Frameworks
Eignung für jeweilige Code- bzw. Programmiersprachen-
Konstellation
Markus Wichmann
41. Web-UI-Testing:
Auswahlkriterien für Test-Frameworks
Aufwand:
Tests einfach zu schreiben
Tests einfach zu warten
Framework einfach aufzusetzen
Wert:
Aussage über Funktionalität
über Lebenszeit der SW als Ganzes hinweg
Verlässlichkeit:
Testergebnis immer korrekt
Falsch-negativer besser als falsch-positiver Test
Markus Wichmann
42. Web-UI-Testing:
Wo ansetzen?
Beispiele für testbare Aspekte aus allen Testing-
Dimensionen:
Test Types --> Funktionale --> Was tut das System?
Test Types --> Struktur --> Aufruf-Hierarchie
Test Types --> Regression
Test Levels --> Component --> Unit, Class, Module
Test Levels --> System --> Entscheidungsbäume, Navigation
Test Levels --> Acceptance --> Anwendungsfälle, Abläufe, Formulare
Test Techniq. --> Dyn. -> Randwerte, Zustandsüberg., Entscheidungsb.
Test Techniq. --> Dyn. -> Anwendungsfälle
Test Techniq. --> Statisch -> Code-Metriken
Test Tools --> Statische, Unit-Test-, Coverage- und Dyn. Analysis Tools
Markus Wichmann
43. Web-UI-Testing:
Wofür welchen Ansatz: Beispiele
Test Types --> Funktionale --> Was tut das System?
Test Types --> Struktur --> Aufruf-Hierarchie
Test Types --> Regression
Test Levels --> Component --> Unit, Class, Module
Test Levels --> System --> Entscheidungsbäume, Navigation
Test Levels --> Acceptance --> Anwendungsfälle, Abläufe, Formulare
Test Techniq. --> Dyn. -> Randwerte, Zustandsüberg., Entscheidungsb.
Test Techniq. --> Dyn. -> Anwendungsfälle
Test Techniq. --> Statisch -> Code-Metriken
Test Tools --> Statische, Unit-Test-, Coverage- und Dyn. Analysis T.
U=Unit-Tests, A=Acceptance-Tests
U A
U
U A
U
A
A
U A
A
U
Markus Wichmann
45. Web-UI-Testing:
Test-Frameworks, Mini-Auszug
Acceptance-Testing: CasperJS
http://casperjs.org
https://github.com/n1k0/casperjs
@casperjs_org
Unit-Testing: z.B. Jasmine (to be implemented)
http://pivotal.github.io/jasmine/
@JasmineBDD
Markus Wichmann
46. Web-UI-Testing:
Allgemeine Test-Anforderungen.
Vorangegangene Folien revisited:
Allgemeines Vorgehen:
1. Finden von Test-Fällen
2. Konstruieren von Tests (und Testdaten)
3. Durchführen von Tests
4. Evaluation, Aufbewahren von Ergebnissen
Allgemeine Anforderungen an Tests:
1. objektiv: PASS, FAIL
2. systematisch: Festlegung Test-Ziele vor Test-Impl.
3. „vollständig“: In sich schlüssige Test-Ergebnisse
4. integral: Beurteilungskriterien SW vor Impl. der SW
Markus Wichmann
47. Web-UI-Testing: Beurteilung anhand
von allgemeiner Test-Kriterien
Allgemeines Vorgehen:
1. Finden von Test-Fällen -> Anforderer, Entw.
2. Konstruieren von Tests -> Entwickler
3. Durchführen von Tests -> Entwickler, CI-Sys.
4. Evaluation, Aufbewahren von Ergebnissen -> CI-Sys.
Allgemeine Anforderungen an Tests:
1. objektiv -> deshalb Automatisierung
2. systematisch -> Anforderer, Entwickler
3. „vollständig“ -> Anforderer, Entwickler
4. integral -> Anforderer
Markus Wichmann
48. Web-UI-Testing: CasperJS 1/2
Technische Features — Kleiner Auszug!
Seiten-Navigation
Melden von JavaScript-Fehlern
Melden fehlender HTTP-Ressourcen
Prüfen auf Vorhandensein von Seiten-Elementen mittels CSS-Selektoren
Warten auf Erscheinen von Elementen (Ajax!)
Werte-Berechnungen wie in JavaScript selbst
Künstliche Maus- und Tastatur-Interaktion
Markus Wichmann
49. Web-UI-Testing: CasperJS 2/2
Fragestellungen hinter den Tests
Seiten-Navigation
Kann sich der Anwender wie gewünscht durch die Anwendung bewegen?
Melden von JavaScript-Fehlern
Wird weitere Bedienung der Anwendung durch Script-Fehler unmöglich?
Melden fehlender HTTP-Ressourcen
Fehlen Bilddateien? Fehlen Scripte (s.o.)? Fehlt Schriftart und somit Icons?
Prüfen auf Vorhandensein von Seiten-Elementen mittels CSS-Selektoren
Liefert die Analyse das Ergebnis oder einen Fehler?
Sieht der angemeldete Anwender die Analysen, die er sehen darf?
Warten auf Erscheinen von Elementen (Ajax!)
Werte-Berechnungen wie in JavaScript selbst
Funktioniert die QuickSelection der Zeitauswahl wie spezifiziert?
Künstliche Maus- und Tastatur-Interaktion
Führt Ändern der Formularwerte zu
a) Enable Apply-Button b) QuickFix c) Änderung anderer Formularwerte d) ...
Markus Wichmann
50. Web-UI-Testing: Unit Testing 1/2
Technische Features — Auszug!
Prüfung Ausgaben von Funktion in Abhängigkeit von Eingaben in Funktion
Prüfung Verhalten einer Klasse, Zusammenspiel von deren Funktionen
Prüfen, ob Funktion mit korrekten Parametern und/oder wie oft aufgerufen
Markus Wichmann
51. Web-UI-Testing: Unit Testing 2/2
Fragestellungen hinter den Tests
Prüfung Ausgaben von Funktion in Abhängigkeit von Eingaben in Funktion
Ist die nächst-grobere vorhandene Granularität nach 1min wirklich 5min?
Ist die Maus-Insensibilität bei einem Auswahlfeld mit vielen
Auswahlmöglichkeiten wirklich geringer als bei einem mit wenigen
Auswahlmöglichkeiten?
Ist Unixtime 1368481500 + 1800 == 1368483300?
Prüfung Verhalten einer Klasse, Zusammenspiel von deren Funktionen
Prüfen, ob Funktion mit korrekten Parametern und/oder wie oft aufgerufen
Funktioniert der Datumssprung bei QuickSelection bei Zeitauswahl?
Wird aus 1368481500 „23:45 Uhr“ und „13. Mai 2013“ errechnet?
Führt ein Aufruf der Methode „increaseBy30m“ zum Addieren von
1800 auf die Variable startUnixTimestamp?
Wird aus dem neuen Wert von startUnixTimestamp erwartungsgemäß
„00:15 Uhr“ und „14. Mai 2013“ errechnet und in Var. xyz geschrieben?
Markus Wichmann
