Testen von Software (german)

Testen von
Software
Allgemeines zum Software-Testing und
Umsetzung am Beispiel eines User-Interfaces
Markus Wichmann

Agenda
Software-Testing allgemein
Web-UI-Testing
Markus Wichmann

Wann testen?
Was testen?
Warum testen?
Auf welcher Grundlage testen?
Markus Wichmann

Wann testen?
Was testen?
Warum testen?
Test-Dimensionen:
Test-Methodik
Test Types
Test Levels
Test Techniques
Test Tools
Markus Wichmann

Software-Testing allgemein:
Wann testen? 1/4
Wann testen?
Was testen?
Warum testen?
Test-Dimensionen:
Test-Methodik
Test Types
Test Levels
Test Techniques
Test Tools
Markus Wichmann

Wann testen? 2/4
Wann testen? Früh. Oft.
Was testen?
Warum testen?
Test-Dimensionen:
Test-Methodik
Test Types
Test Levels
Test Techniques
Test Tools
Markus Wichmann

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

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

Was testen? 1/3
Wann testen? FRÜH!
Was testen?
Warum testen?
Test-Dimensionen:
Test-Methodik
Test Types
Test Levels
Test Techniques
Test Tools
Markus Wichmann

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

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

Warum testen? 1/2
Wann testen? FRÜH!
Was testen? Anforderungen.
Warum testen?
Test-Dimensionen:
Test-Methodik
Test Types
Test Levels
Test Techniques
Test Tools
Markus Wichmann

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

Auf welcher Grundlage testen? 1/2
Wann testen? FRÜH!
Warum testen? Aussagen über Systemreife.
Test-Dimensionen:
Test-Methodik
Test Types
Test Levels
Test Techniques
Test Tools
Markus Wichmann

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

Test-Dimensionen
Wann testen? FRÜH!
Warum testen? Aussagen über Systemreife.
Auf welcher Grundlage testen? Anforderungen.
Test-Dimensionen:
Test-Methodik
Test Types
Test Levels
Test Techniques
Test Tools
Markus Wichmann

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

Test-Dimensionen: Test Types 1/5
Funktionale Tests
Nicht-funktionale Tests
Struktur-Tests
Regression-Tests
Markus Wichmann

Funktionale Tests
○ Frage: „Was tut das System?“
○ Test Levels: alle (dazu später)
○ Methodik: Black-Box
Markus Wichmann

Nicht-funktionale Tests
○ Frage: „Wie tut das System, was es nunmal tut?“
○ Methodik: Black-Box
Markus Wichmann

Struktur-Tests
○ Zusammenarbeit von Teilen der Software
○ Aufrufhierarchie
○ Architektur
○ etc.
Markus Wichmann

Regression-Tests
○ Wiederholtes Testen bereits getesteter Dinge
nach erneuten Änderungen
○ Tests müssen vor und nach Änderungen gleich sein
○ beinhalten(!)
○ funktionale
○ nicht-funktionale und
○ Struktur-Tests
Markus Wichmann

Test-Dimensionen: Test Levels 1/6
Component Tests
Integration Tests
System Tests
Smoke Tests
Acceptance Tests
Markus Wichmann

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

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

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

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

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

Test-Dimensionen: Test Techniques 1/3
Static Techniques (=Code-Untersuchung ohne dessen Ausführung)
Test Design Techniques (aka Dynamic Techniques)
Markus Wichmann

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

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

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

Agenda
Web-UI-Testing: Wo ansetzen?
Markus Wichmann

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

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

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

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

Web-UI-Testing:
Wofür welchen Ansatz?
Acceptance- und Unit-Testing ergänzen sich!
Markus Wichmann

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

Web-UI-Testing:
Allgemeine Test-Anforderungen.
Vorangegangene Folien revisited:
1. Finden von Test-Fällen
2. Konstruieren von Tests (und Testdaten)
3. Durchführen von Tests
4. Evaluation, Aufbewahren von Ergebnissen
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

Web-UI-Testing: Beurteilung anhand
von allgemeiner Test-Kriterien
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.
1. objektiv -> deshalb Automatisierung
2. systematisch -> Anforderer, Entwickler
3. „vollständig“ -> Anforderer, Entwickler
4. integral -> Anforderer
Markus Wichmann

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

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

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

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

Danke.
http://www.istqb.org
http://jagielu.com/2013/01/28/caspers-for-java-developers/
http://www.codeproject.com/Articles/37132/Painless-Automated-Web-UI-Testing
http://www.informatik.hs-bremen.de/spillner/WWW-Talks/WuerzburgGI200911105V1
http://www.sei.cmu.edu/productlines/frame_report/testing.htm
Markus Wichmann

Testen von Software (german)

Weitere ähnliche Inhalte

Andere mochten auch

Testen von Software (german)