Testen von Software (german)

980 Aufrufe

Veröffentlicht am

Allgemeines zum systematischen Testen von Software (german, on testing software systematically)

Veröffentlicht in: Technologie
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
980
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
5
Aktionen
Geteilt
0
Downloads
7
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Testen von Software (german)

  1. 1. Testen von Software Allgemeines zum Software-Testing und Umsetzung am Beispiel eines User-Interfaces Markus Wichmann
  2. 2. Agenda Software-Testing allgemein Web-UI-Testing Markus Wichmann
  3. 3. Agenda Software-Testing allgemein Web-UI-Testing Markus Wichmann
  4. 4. Software-Testing allgemein Wann testen? Was testen? Warum testen? Auf welcher Grundlage testen? Markus Wichmann
  5. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  21. 21. Software-Testing allgemein: Test-Dimensionen: Test Types 1/5 Funktionale Tests Nicht-funktionale Tests Struktur-Tests Regression-Tests Markus Wichmann
  22. 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. 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
  24. 24. Software-Testing allgemein: Test-Dimensionen: Test Types 4/5 Struktur-Tests ○ Zusammenarbeit von Teilen der Software ○ Aufrufhierarchie ○ Architektur ○ etc. Markus Wichmann
  25. 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. 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
  27. 27. Software-Testing allgemein: Test-Dimensionen: Test Levels 1/6 Component Tests Integration Tests System Tests Smoke Tests Acceptance Tests Markus Wichmann
  28. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  39. 39. Agenda Software-Testing allgemein Web-UI-Testing: Wo ansetzen? Markus Wichmann
  40. 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. 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. 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. 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
  44. 44. Web-UI-Testing: Wofür welchen Ansatz? Acceptance- und Unit-Testing ergänzen sich! Markus Wichmann
  45. 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. 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. 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. 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. 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. 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. 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
  52. 52. 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

×