Testing. Modul Software Komponenten. Roland Gisler. Inhalt

Transkript

1 Modul Software Komponenten Testing Roland Gisler Inhalt 1. Testing Einführung 2. Motivation für Testing 3. Testarten, Unit-Testing 4. Test-First-Ansatz 5. Übungen 1 (Test-First Ansatz) 6. Messen der Codeabdeckung von Tests 7. Code Coverage (Grundlagen) 8. Übungen 2 (Code Coverage) 9. Weiterführende Möglichkeiten 10. Zusammenfassung und Quellen Modul SWK - (C) 2008 Roland Gisler 2

2 Testing Einführung Grundlagen zu Software-Testing Modul SWK - (C) 2008 Roland Gisler 3 Software Testing -Einführung Bei vielen EntwicklerInnen verpönt und unbeliebt. Warum? Ich kann programmieren, ich mache keine Fehler Ich will programmieren, nicht testen Ich muss den Termin einhalten, es muss schon fertig sein => Testen hat leider (und zu unrecht!) noch vielerorts ein schlechtes Image und ist 'uncool'... einerseits in einzelnen Köpfen (EntwicklerInnen) andererseits aber auch in der Firmenkultur Aber: Tests gewährleisten, dass speziell auch wichtige Software möglichst fehlerfrei arbeiten, so zum Beispiel: Modul SWK - (C) 2008 Roland Gisler 4

3 Software die (gut) getestet wird... steuert Software viele medizinische Geräte im Spital Herz-/Kreislaufmaschine, Beatmungsgerät, Infusion etc. Beispiel: Blutanalysegeräte von Roche kontrolliert und steuert verschiedenste Verkehrsmittel Luftraumüberwachung, Autopilot, Zugbeeinflussung, ABS, Airbag etc. Beispiele: Ariane, Kampfflugzeug steuert aufwändige und komplizierte Prozesse Beispiele: Chemische Industrie, Atomkraftwerke, Sicherheit Frage: Möchte jemand in diesen Bereichen auf das Testen verzichten und auf den 'genialen Programmierer' vertrauen? Modul SWK - (C) 2008 Roland Gisler 5 Problem: Typischer Abläufe in der Entwicklung Analyse, Design, Implementation, Testen... Auch wenn Iterativ gearbeitet wird, kommt das (grosse) Testen immer erst am Schluss Konsequenz: Man Testet um Fehler zu finden, die man eigentlich gar nicht machen, und somit auch nicht finden möchte! "Finde ich beim Testen einen Fehler, muss ich den ja auch noch korrigieren, und man glaubt ich habe schlecht gearbeitet." Berühmter Irrglaube und Rechtfertigung: "Wer keine Fehler findet, hat auch keine gemacht." Oder etwa nur einfach nicht getestet? Modul SWK - (C) 2008 Roland Gisler 6

4 Testing: Motivation Warum testen von Software Spass macht! Modul SWK - (C) 2008 Roland Gisler 7 Motivation für Testen Nicht: Wir testen nur um Fehler zu finden! Sondern: Wir testen kontinuierlich schon während der Implementation, um von Anfang an die Bestätigung zu haben dass es funktioniert! Fehler finden bevor man Sie gemacht hat! Fehler korrigieren bevor man Sie implementiert hat! Oder mindestens Fehler schon im Ansatz (wenn es noch niemand anders gemerkt hat) finden! Ansatz: Test-First! Modul SWK - (C) 2008 Roland Gisler 8

5 Testarten Verschiedene Arten von Tests Modul SWK - (C) 2008 Roland Gisler 9 Testarten - Überblick Integrationstests, (Teil-)Systemtest Unit- und Komponententest (Entwicklertest) Modul SWK - (C) 2008 Roland Gisler 10

6 Integrationstest / Systemtest Integration: Integration der Komponente / des Systems in die bestehende SW-Landschaft korrekte Interaktion, fehlerfreie Installation, Kompatibilität, Performance etc. => technische Sicht System: Testen eines gesamten (Teil-)Systems auf Basis der Spezifikation fachliche Korrektheit, Usability etc. => eher Benutzersicht Integrations- und Systemtests müssen explizit in einer Phase geplant, organisiert und durchgeführt werden (klassisches Testen) z.t. beträchtlicher Aufwand für Testumgebung: Bereitstellung und Konfiguration der Umsysteme, von Testdaten etc. Modul SWK - (C) 2008 Roland Gisler 11 Integrationstest / Systemtest: Nutzen Positiv: speziell in komplexen Systemen fundamental für eine erfolgreiche Inbetriebnahme/Einführung meist gut etabliert und akzeptiert interdisziplinäre Zusammenarbeit (Informatik mit Fach) Negativ: relativ grosser Aufwand Fehler werden erst spät aufgedeckt, somit Fehlerbehebung aufwändig und teuer Modul SWK - (C) 2008 Roland Gisler 12

7 Unit-Tests Häufig mit Komponenten-, Modul- und Entwicklertests gleich gesetzt funktionaler Test von einzelnen, in sich abgeschlossenen Units (Klasse, Komponente, Modul) Ziel: schnelle, einfach auszuführende, automatisierte Tests ohne Abhängigkeiten von Umsystemen werden während der Entwicklung ausgeführt innerhalb der Entwicklungsumgebung (IDE) innerhalb des Buildprozesses Unterstützung durch Frameworks (z.b. JUnit) Modul SWK - (C) 2008 Roland Gisler 13 Unit-Tests: Nutzen Positiv: neue oder veränderte Komponenten können schnell getestet werden Testen vollständig in die Implementationsphase integriert Test-First Ansatz möglich automatisiertes, übersichtliches Feedback / Reporting Integration von Coverage-Messungen möglich Negativ: für GUI(-Komponenten) schwieriger durchführbar Qualität und Nachvollziehbarkeit der Testfälle muss im Auge behalten werden (Qualität vor Quantität) Modul SWK - (C) 2008 Roland Gisler 14

8 Unit-Tests: Bilanz Nutzen unbestritten Qualität abhängig von einzelner/m EntwicklerIn Unterstützung durch Frameworks in nahezu jeder Sprache und Entwicklungsumgebung Aber: Hier wird meist zuerst gespart, was sich später sehr stark rächen kann. Modul SWK - (C) 2008 Roland Gisler 15 Test-First Test-First - Ansatz aus XP Modul SWK - (C) 2008 Roland Gisler 16

9 Test-First-Methode Entwickelt aus XP (extrem programming, u.a. von E. Gamma) Ganz einfacher Ansatz: Vor der Implementation immer zuerst die Testfälle schreiben! Vorteile: Während dem Schreiben der Testfälle denkt man unmittelbar auch an die konkrete Implementation des zu testenden Codes. Dabei 'reift' diese buchstäblich heran! Typisch fallen einem dabei viele Ausnahmen und Sonderfälle ein, welche man bei der Implementation der eigentlichen Komponenten dann 'automatisch' auch berücksichtigt. Kaum ist die Komponente fertig, kann Sie sofort getestet werden! Modul SWK - (C) 2008 Roland Gisler 17 Test-First-Methode sehr einfacher, aber genialer Ansatz! basiert technisch auf Unit-Tests arbeitet problemlos mit bewährten Unittest-Werkzeugen zusammen, ergo alle Vorteile von Unit-Tests Einziger 'Haken': Man muss es machen! Modul SWK - (C) 2008 Roland Gisler 18

11 Messung der Codeabdeckung von Tests Problem: Wie kann man die Qualität von Unit-Tests beurteilen und verbessern? Ziel: Mit möglichst geringem Aufwand einen möglichst umfassenden Testfall implementieren => Effizienz! Lösung: Messen der Codeabdeckung von Testfällen während der Ausführung der Tests wird von der Laufzeitumgebung gemessen, welche Statements / Codezeilen tatsächlich abgearbeitet wurden! statistische Aufbereitung der Daten nach Testfall, Komponente, Package, Teilsystem etc. z.t auch historisiert, d.h. zeitliche Entwicklung der Werte Modul SWK - (C) 2008 Roland Gisler 21 Code Coverage -Demonstration Beispiele zur Messung der Codeabdeckung Variante 1: ANT-Build, Cobertura (open source) Variante 2: ANT-Build, Clover (Kommerziell) Modul SWK - (C) 2008 Roland Gisler 22

12 Code Coverage Grundlagen der Code Coverage Modul SWK - (C) 2008 Roland Gisler 23 Was ist Code Coverage? Code Coverage ist eine Metrik welche zur Laufzeit misst, welche Quellcodezeilen abgearbeitet wurden. Diese Messung wird typisch mittels Ausführung der Unit- Testfälle (z.b. mit JUnit) durchgeführt. Somit kann eine Aussage gemacht werden, wie umfassend der Code tatsächlich getestet wurde! Verbesserung der SW-Qualität durch besser Qualität der Testfälle Effizienzsteigerung der Testfälle Modul SWK - (C) 2008 Roland Gisler 24

13 Was wird gemessen? Man unterscheidet verschiedene Messtechniken Statement Coverage (Line Coverage) Decision Coverage (Branch Coverage) Path Coverage Function Coverage Race Coverage Unterschiedlich Aufwändig und Aussagekräftig Modul SWK - (C) 2008 Roland Gisler 25 Was wird gemessen? Statement Coverage Misst, ob und wie häufig eine einzelne Codezeile durchlaufen wurde. Problem: Handelt es sich bei der Zeile um einen logischen Vergleich, ist ein einmaliger Durchlauf nicht repräsentativ Decision Coverage Bei Fallunterscheidungen (if, while etc.) wird zusätzlich geprüft, dass beide Fälle (true und false) aufgetreten sind. Modul SWK - (C) 2008 Roland Gisler 26

14 Was wird gemessen? Path Coverage Bei der Path Coverage wird gemessen, ob alle möglichen Kombinationen von Programmablaufpfäden durchlaufen wurden. Problem: Die Anzahl der Möglichkeiten steigt exponential mit der Anzahl Entscheidungen Function Coverage Misst auf der Basis der Funktionen ob sie aufgerufen wurden Race Coverage Konzentriert sich auf Codestellen die parallel ablaufen. Modul SWK - (C) 2008 Roland Gisler 27 Was wird gemessen? Die meisten Code Coverage-Werkzeuge auf dem Markt unterstützen 'nur' Statement- und Decision-Coverage, teilweise noch Path Coverage. Dennoch liefern sie damit schon sehr wertvolle Aussagen, z.b.: Codeteile die beim Test schlicht vergessen wurden Ausnahmen, die nicht berücksichtigt wurden. Modul SWK - (C) 2008 Roland Gisler 28

15 Funktionsweise Instrumentierung des Quellcodes Der Quellcode wird durch einen Preprocessor vor dem Compilieren mit Statements zur Coverage-Messung ergänzt Instrumentierung des Bytecodes Der Bytecode wird bei der Compilierung (modifizierter Compiler), oder unmittelbar danach von einem Postprocessor mit Bytecode zur Coverage-Messung ergänzt. Modifizierte VM (im Falle von Java) Instrumentalisiert den Bytecode unmittelbar bei dessen Ausführung. Modul SWK - (C) 2008 Roland Gisler 29 Nachteile der Code Coverage Messung Instrumentierter Code ist langsamer nicht geeignet für zeitkritische Systeme Instrumentierter Code muss gesondert behandelt werden darf / sollte nicht in die produktive Distribution / Deployment gelangen Ausschliesslich für die Ausführung der Testfälle Modul SWK - (C) 2008 Roland Gisler 30

16 Auswertung / Integration Generierung von Reports (HTML) Bequem, wird von den meisten Produkten unterstützt. Kann problemlos automatisiert werden (Build-Process) Analyse mittels freistehender Anwendung Erweiterte Funktionalität, Verlinkung etc. Für interaktive Detailanalyse Integration in Entwicklungsumgebung Praktisch während der unmittelbaren Entwicklung von Testfällen. Modul SWK - (C) 2008 Roland Gisler 31 Herausforderungen Eine 100%-ige Abdeckung ist eine Illusion! Erreichbare Abdeckung stark abhängig von Projekttyp Automatisierbare Testfälle als Grundlage Exceptionhandlingist eine Herausforderung Realistische Werte liegen im Bereich von 40-70% Projektspezifisch festlegen Kann im Build-Prozess automatisch geprüft werden Modul SWK - (C) 2008 Roland Gisler 32

18 Testen - weitere Möglichkeiten - 1/3 Software-Metriken zur Identifikation von grossen Methoden, fetten Klassen, tiefen Vererbungen etc. komplexen, und somit fehleranfälligen Quellcodestellen Können in Testfälle eingebaut werden => Failure wenn Grenzwerte überschritten werden! Profiling / Performance und Memory Messen des Zeit- und Memorybedarfs einer Anwendung oder einzelner Komponenten Welche Methoden benötigen am meisten Laufzeit? Welche Algorithmen benötigen viel Memory? Wo sind evt. Memory-Leaks? Modul SWK - (C) 2008 Roland Gisler 35 Testen - weitere Möglichkeiten - 2/3 Mocking -Mock Objects erlauben die Simulation von ansonsten komplexen Umsystemen mittels Stubs Mock Objects an der Stelle der 'echten' Objekte enthalten minimale Logik um übergebene Parameter zu validieren und sinnvolle Testwerte/-daten zurückgeben zu können Unterstützung durch verschiedene Frameworks FitNesse -Testing Framework kombiniert mit Wiki und Collaboration Testdaten in Wiki dynamisch erfassen und erweitern Teilweise 'fachtauglich', sprich für fachliche TesterInnen Modul SWK - (C) 2008 Roland Gisler 36

19 Testen - weitere Möglichkeiten - 3/3 Continuous Builds und Continuous Integration ebenfalls aus dem XP-Ansatz entstanden Buildserver welche kontinuierlich das gesamte Projekt builden und Testfälle ausführen Builds bei Änderungen im SCM-Tool (cvs, svn etc.) regelmässige Builds (z.b. Nightly-Build) manuell ausgelöste Builds Aufbereitung detaillierter Statistiken und Metriken Durchführung von umfangreicheren Testfällen mehr Resourcen zur Verfügung und vieles anderes mehr... Modul SWK - (C) 2008 Roland Gisler 37 Zusammenfassung und Quellen Modul SWK - (C) 2008 Roland Gisler 38

20 Zusammenfassung Nicht nachträgliches Testen zur Fehlersuche, sondern kontinuierliches Testen zur Bestätigung dass es funktioniert! Test-First - Ansatz als sehr attraktive Methode aus dem XP- Ansatz Unterstützung durch zahlreiche Werkzeuge, Frameworks, Plugins etc. Vollständige Integration der Unit-Tests in die Implementationsphase des Projektes Messung der Code Coverage als Motivationsfaktor (Beispiel) Testen macht Spass! Modul SWK - (C) 2008 Roland Gisler 39 Quellen 1 JUnit Testframework, Coverage, Open Source (Beispiele): Cobertura, Emma, Coverage, kommerziell (Beispiele): Clover, JProbe, FitNesse TestingFramework undwiki, Modul SWK - (C) 2008 Roland Gisler 40

21 Quellen 2 Buildserver, Open Source (Beispiele): CruiseControl, Continuum, Buildserver, kommerziell (Beispiele): TeamCity, Mocking Frameworks, Open Source (Beispiele): EasyMock, MockRunner, jmock, Modul SWK - (C) 2008 Roland Gisler 41