Testing Today - Seminar Sommersemester Dipl.-Math. Raphael Pham, Prof. Kurt Schneider

Transkript

1 Sommersemester 2015 Dipl.-Math. Raphael Pham, Prof. Kurt Schneider

2 Heute Überblick über relevante Research Topics Vergabe der Themen 2

3 Aktuelle Forschungsthemen im Software Testing 3

4 Definition: Software testen Software testen Vorlesung: Ausführen eines Programms mit dem Ziel Fehler zu finden. globaler: kontinuierilche Aktivität, die den gesamten Entwicklungsprozess begleitet, um Eigenschaften und Fähigkeiten der Software zu messen und sicherzustellen Umgangsprachlich: Ausführen der Software nicht alle Möglichkeiten beobachten der Ausführung bewerten dieser Ausführung (korrekt? inkorrekt?) 4

5 Facetten des Testens WHY: Was wollen wir herausfinden? HOW: Wie soll der Test gestaltet werden? Welcher Test soll ausgeführt werden? HOW MUCH: Wie viel testen und wann aufhören? WHAT: Welchen Teil der Software testen? WHERE: In welcher Umgebung? WHEN: Wann soll getestet werden? Im Entwicklungsprozess? 5

6 Übersichtsbild 6

7 Errungenschaften Testen als kontinuierliche Aktivität beim Entwicklen wahrgenommen neue Testprozesse vom V-Modell (zu bürokratisch) zu Test-Driven-Development (agiler) Testkriterien: Strategie zum Konstruieren von Testfällen Blackbox: anhand von Funktionen testen Whitebox: anhand von Struktur testen Beispiel: Statement Coverage, Branch Coverage, Path Coverage, welche Strategie anwenden? Kombination davon? Verständnis: welche Strategie ist besser? in welcher Situation? 7

8 Ultimative Ziele 1. Theorie des Testens 2. Test-basierte Modellierung 3. vollständige Testautomatisierung 4. volle Effektivität und Effizienz 8

9 1) Universelle Theorie des Testens Übersicht zu: Vorteile, Nachteile von Ansätzen Was sollte ich wann benutzen? In meiner Situation? Testeffektivität welche Ansätze sind wie effektiv im Fehlerfinden? welche Grenzen haben sie? Komposition der Tests optimale Reihenfolge der Tests à Wiederverwendung von Tests und Ergebnissen Testen von Units à Aussagen über Integration möglich? Welche Integrationstests noch nötig? 9

10 1) Universelle Theorie des Testens Empirisches Wissen über Einsatz eines Testansatzes Informationen aus *realen* Anwendungen: in Firmen! Hat es funktioniert? Gut? Schlecht? Wie können wir den Ansatz verbessern? Meisten Erfahrungsberichte: Punktuell nur in spezieller Situation (z.b. bei VW genau mit dieser Android App, ) keine allgemeinen Schlüsse möglich gemeinsame und übergreifende Initiative zum Sammeln und Vervollständigen von empirischen Erfahrungen z.b. Wiederholen von Situationen an anderen Standorten zusammen geteilte Datensätze für Forscher 10

11 Ultimative Ziele 1. Theorie des Testens 2. Test-basierte Modellierung 3. vollständige Testautomatisierung 4. volle Effektivität und Effizienz 11

12 2) Test-basiertes Modellieren eigentlich: Modell-basiertes Testen! SW immer komplexer, traditionelles Testen unökomomisch formale Modelle zum Konstruieren von AUT verwenden z.b. UML sollte ja eigentlich verwendet werden! daraus Testfälle generieren automatisch erkennen: alles ist korrekt! schöner: Test-basiertes Modellieren formales Modell so verwenden und mit Informationen bereichern, dass Testfälle einfach generiert werden können Design-for-Testability Controllability of inputs Observability of outputs 12

13 2) Test-basiertes Modellieren industrielle Adoption? nicht alle Praktiker formalisieren ihren Entwicklungsansatz selbst UML wird nicht überall verwendet Hürden! jeder benutzt andere Modelle für verschiedene Situationen Kombination von Modellen betrachten test-basiertes modellieren sollte nicht abhängig vom gewählten Modell sein! Kombinationen von Modellen zulassen Tracing von Anforderungen über Modelle hinweg (OL) Integration in den Entwicklungsprozess mit starken Tools 13

14 2) test-basiertes Modellieren anti-modell-basiertes testen Modell nicht immer vorhanden (zu teuer, System verändert sich zu stark und Modell veraltet) Modell nicht vorher definieren, sondern nachher extrahieren: Anhand der laufenden Software --- reverse engineering Invarianten in Variablen erkennen, LTS, Sequence Diagrams, extrahieren diese Eigenschaften dann austesten 14

15 2) test-basiertes Modellieren Test Oracle Tests ohne Urteil sind wertlos woher kommt das Urteil sonst? Requirements, Modell, Test Oracle erklärt, ob ein beobachtetes Verhalten (Output) korrekt oder falsch ist ideal: hat für jeden Testfall den Sollwert parat precision: falsches Verhalten erkennen; richtiges Verhalten durchlassen Modelle können Oracle sein: müssen aber formal genug sein! Textuelle Requirements sind auch ein Modell Wer kann solch formale Modelle bieten? In der Praxis? 15

16 Ultimative Ziele 1. Theorie des Testens 2. Test-basierte Modellierung 3. vollständige Testautomatisierung 4. volle Effektivität und Effizienz 16

17 3) vollständige Testautomatisierung ideal: Testsuite instrumentiert AUT selbstständig generiert Test-setup-code (setups, stubs, teardowns, ) enthält wichtigste Testfälle und führt diese aus wirft einen Bericht aus! Directed Automated Random Testing (DART) automatisierte Interface-Extraction (statische Source-Code-Analyse) automatische Test-Code-Generierung zum Ansprechen des Interfaces dynamische AUT-Analyse bei zufälliger Ausführung Ziel: alle und alternative Programmpfade ausführen und abdecken honorable mention: per Hand - UnitTesting (JUnit, z.b.) wird oft weggelassen: viel (!) test-setup-code ist teuer, aufwändig (RP: Praktiker! SWP!) 17

18 3) vollständige Testautomatisierung Software Agitation verschiedene Analysen kombiniert symbolic execution, contstraint solving, directed random input generation for input data Automatisch ausführbaren Testcode generieren On-Line Testing AUT in Benutzung analysieren (runtime analysis) verhält sie sich wie erwartet? Vorteil: Keine Testsuite nötig, um Umwelt zu simulieren Beobachtung und Nachrichten senden können AUT verlangsamen meistens passive Beobachtung 18

19 Ultimative Ziele 1. Theorie des Testens 2. Test-basierte Modellierung 3. vollständige Testautomatisierung 4. volle Effektivität und Effizienz 19

20 4) volle Effektivität und Effizienz kosten-effizientes (günstig) testen bei maximaler Effektivität (Fehler finden) angestrebt alle Ansätze zu praktikablem Prozess vereint technische Hürden versteckt, leicht zu benutzende IDE Development Process und Design for Testability Testen und AUT-Evolution Regression Testing muss effizienter und effektiver werden gezieltes retesting, gesamte Testsuite? Test Factoring: alte, große Tests aufbrechen in kleine Tests gezieltere Aussagen zum Fehlerort und selective Regression Testing FSE2014: Google adaptiert seine Test Suites dynamisch, führt nicht alles aus 20

21 4) volle Effektivität und Effizienz Populationen und Real-World verwenden nicht jede Umgebungskonfiguration kann nachgestellt werden z.b.: jedes Android-Handy auf dem Markt Daten direkt von Usern einsammeln reale Probleme von Usern ermitteln Component-Interaction-Testing in Smartphones (ICSE2012) Ausbildung von Software Testern skill, commitment, motivation! leicht zu benutzende Tools! verfügbare Techniken kennen: Vorteile und Grenzen aktuell bleiben! (Forschungspunkt von RP) 21

22 Zeitlicher Ablauf Nr. Datum Thema Organisatorisches Übersicht: Testen & Forschung Ausgabe der Themen Übersicht: Testen & Praxis Wie wird testen gelehrt? Praktische Projekte Wie wird testen gelehrt? Alternative Lehransätze Praktikermeinungen zur Testausbildung (De)Motivation beim Software Testen Arbeiten mit Testframeworks Industrielle Akzeptanz von Test-Driven-Development (TDD) Schwierigkeiten bei der Testautomatisiertung Ökonomische Sicht auf die Testautomatisierung Aufbau einer Testorganisation in der Wirtschaft Praktisches testen bei Google 22