Se ha denunciado esta presentación.
Se está descargando tu SlideShare. ×
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Cargando en…3
×

Eche un vistazo a continuación

1 de 16 Anuncio
Anuncio

Más Contenido Relacionado

Presentaciones para usted (17)

Similares a Test-Alternativen (20)

Anuncio

Más reciente (20)

Test-Alternativen

  1. 1. e-movimento Software Design & Beratung GmbH 1030 Wien ● Marxergasse 7/26 ► www.e-movimento.com Effizientere und effektivere Alternativen zum Testen DI Sebastian Dietrich Sebastian.Dietrich@e-movimento.com
  2. 2. Testen Warum testen wir?  Warum testen wir?  Warum schreiben wir Unit-Test?  Warum schreiben wir Integrationstests?  Warum schreiben wir Testfälle? Warum führen wir Testfälle durch? Um Kosten zu reduzieren  Entwicklungskosten, Wartungskosten  Fehlerbehebungskosten  Imagekosten  …  Wieviel darf uns daher der Test kosten? Performancetests Securitytests Penetrationtests Integrationstests Systemtests Loadtests Abnahmetests Usablity Test Unit-Tests Lasttests Regressiontests Fehlertests Schnittstellentests Installationstests Crashtests Smoketests Stresstests ► www.e-movimento.com, Sebastian Dietrich2
  3. 3. Systemtest Kosten – Nutzen Rechnung Kosten Nutzen Systemtestaufwand: ~ 1 PT / Testfall Systemtest findet ~ 1 Fehler / Testfall Fehlerbehebungsaufwand: ~ 1PT / Fehler (10x wie während Entwicklung) Je behobener Fehler: 0,5 – 0,8 neue (unentdeckte) Fehler 80 – 150% der Entwicklungskosten Systemtest findet max. 25 – 55% der Fehler Systemtest: Teststufe, bei der das gesamte System gegen die gesamten Anforderungen getestet wird. [Jones 86], [Jones 96a], [Jones 96b], [Shull 02], [McConnell 04] ► www.e-movimento.com, Sebastian Dietrich3
  4. 4. Unittest Kosten – Nutzen Rechnung Kosten Nutzen Unit-Testaufwand: ~ 2-3x Entwicklungsaufwand „Code Coverage“ ? „Refactoring“ ? Fehlerbehebungsaufwand: ~ 1h / Fehler (1/10 wie während Test) Je behobener Fehler: 0,5 – 0,8 neue (unentdeckte) Fehler ~ 50% der Entwicklungskosten Unit-Test findet max. 15 – 70% der Fehler Unit-Tests: Teststufe, bei der funktionale Einzelteile (Module) auf korrekte Funktionalität geprüft werden. [Jones 01], [Humphrey 89], [Software Metrics 01] ► www.e-movimento.com, Sebastian Dietrich4
  5. 5. Unittests Warum gute Unittests so teuer sind  Gute Unittests (gilt auch für TDD):  Haben Assertions (die den Vertrag der Methoden testen):  Vorbedingungen (typische / untypische / extreme / unerlaubte)  Nachbedingungen (Rückgabewerte & Exceptions, State-Änderungen)  Invarianten (was sich nicht ändern darf)  Haben 100% Assertion-Coverage (Code-Coverage ist unwichtig)  Testen Units (& mocken Referenzen auf andere Units weg)  Berücksichtigen State (Quasimodale & Modale Klassen) und Reihenfolge der Methodenaufrufe (Unimodale & Modale Klassen)  Hinterlassen das System, wie sie es vorgefunden haben  Laufen daher in beliebiger Reihenfolge  Sind Refactoring-Safe  Testen auch das Design (z.B. Liskovsches Substitutionsprinzip)  Laufen auf dem CI Server & geben rasches Feedback (< 1 min.) ► www.e-movimento.com, Sebastian Dietrich5
  6. 6. Testen Fazit und Alternativen  Fazit:  Testen ist sehr aufwändig (lt. Literatur 15%-70% Gesamtaufwand)  Testen findet bei weitem nicht alle Fehler (max. 80%) Wir benötigen Test-Ende Kriterien und Alternativen  Alternativen:  Exploratives Testen  Code-Reviews  Test-Driven Development  Behavior-Driven Development ► www.e-movimento.com, Sebastian Dietrich8 finden / verhindern mehr Bugs pro Zeiteinheit als Testen
  7. 7. Testen Test-Ende Kriterien  Test-Ende Kriterien:  Wenn Anzahl der zu findenden Fehler gefunden wurden… 𝐾𝑆𝐿𝑂𝐶𝑡𝑒𝑠𝑡𝑒𝑑 × 2 + 𝐾𝑆𝐿𝑂𝐶¬𝑡𝑒𝑠𝑡𝑒𝑑 × 20 < 𝐵𝑢𝑔𝑠 𝑒𝑥𝑝 < 𝐾𝑆𝐿𝑂𝐶𝑡𝑒𝑠𝑡𝑒𝑑 × 10 + 𝐾𝑆𝐿𝑂𝐶¬𝑡𝑒𝑠𝑡𝑒𝑑 × 50  Wenn Kosten für Test > Kosten von Fehlern in Produktion… ► www.e-movimento.com, Sebastian Dietrich9
  8. 8. Testen Test-Ende Kriterien?  Test-Ende Kriterien:  Wenn Fehlerdichte genügend ist… (Kommerzielle Software ~15 – 50, Microsoft-Anwendungen ~0,5)  Wenn Aufwand pro gefundenem Fehler zu hoch wird… Fehlerdichte Klassifizierung < 0,5 stabile Programme 0,5 … 3 reifende Programme 3 … 6 labile Programme 6 … 10 fehleranfällige Programme > 10 unbrauchbare Programme 20 – 50 ungetestete Programme Schadenersatz potentiell Schadenersatz # Bugs ► www.e-movimento.com, Sebastian Dietrich10
  9. 9. Test Alternativen Exploratives Testen vs. klassischer Test  Gleiche Fehlererkennungsrate  gleiche Effektivität  Weniger Vorbereitung  höhere Effizienz  Bugs schneller gefunden  schnelleres Feedback  Weniger False-Positives ► www.e-movimento.com, Sebastian Dietrich11 Testen Test Design Lernen [Itkonen, Mäntylä 13]
  10. 10. Code-Reviews Kosten – Nutzen Rechnung Kosten Nutzen Reviewaufwand: ~ 1 PT / Modul (~100 Klassen) Reviews finden: technische Fehler 2-4x schneller Bugs als Tests Fehlerbehebungsaufwand: wenige Minuten bis Monate (Architekturfehler) Weitere Fehler werden sichtbar Verbreitetes Wissen, Weiterbildung Lesbarkeit = Wartbarkeit 10% (kontinuierlich) - 105% (nachträglich) des Entwicklungsaufwand Reviews finden 20-90% der Fehler (je Review-Art) Code-Reviews: Statische Testmethode, bei der Code und Architektur (manuell) geprüft werden. [Jones 02], [Fagan 76], [Brown 99], [Russel 91] ► www.e-movimento.com, Sebastian Dietrich12
  11. 11. Test Alternativen Code Reviews Bessere technische Qualität (automatische) Reviews & Qualitätsverbesserungen Weniger Fehler (nach Entwicklung) Bessere technische Qualität Mehr Entwicklungsaufwand Weniger Gesamtkosten Höhere Produktivität (während Entwicklung) Weniger Wartungsaufwand Weniger Testaufwand Weniger Fehler- behebungsaufwand ca.10% 18%-81% 10%-105% 50%-170% min. 20% 11%-73% ► www.e-movimento.com, Sebastian Dietrich13 min. 10% 20% - 90%
  12. 12. Test-Driven Development Kosten – Nutzen Rechnung Testmethode, bei der der Entwickler konsequent Modultests entwickelt bevor er die Module entwickelt. Kein Codieren, „nur“ Tests fixen! [George & Williams 03] ► www.e-movimento.com, Sebastian Dietrich14 Kosten Nutzen TDD-Aufwand: + 16% Entwicklungsaufwand 18% weniger Bugs als wenn Tests nach Code Fehlerbehebungsaufwand: keiner – Codieren = Fehler fixen 2 Hüte  Besseres Design Testbarer Code = Besseres Design TDD findet max. 33 – 88% der Fehler
  13. 13. Test Alternativen Behavior-Driven Development (BDD)  Typische Probleme beim Testen (bei denen BDD hilft):  TDD weiss nicht wo man anfangen kann  Zuerst Features automatisieren (Tests brechen), dann mittels TDD Features umsetzen  Spezifikation ist ungenau / mehrdeutig / veraltet  eindeutigere, testbare Spezifikationen  Features brechen, wenn veraltet  Dinge, die bereits funktionierten, funktionieren nicht mehr  Abdeckung aller Features mit Tests  Fail Fast  GUI- und Schnittstellen ändern sich laufend  hoher Wartungsaufwand für GUI- und Schnittstellentests  BDD zunächst auf Serviceebene, dann auf Page Objects ► www.e-movimento.com, Sebastian Dietrich15
  14. 14. Test Alternativen Was ist die beste Alternative? ► www.e-movimento.com, Sebastian Dietrich16 Was aber verhindert Bugs am effektivsten? (... und ist nebenbei wichtigster Faktor für den Projekterfolg?) 50% aller Bugs? 60% aller Bugs? 70% aller Bugs? 80% aller Bugs? 90% aller Bugs?
  15. 15. Test Alternativen Was ist die beste Alternative?  Weniger Features, weniger Code, weniger Bugs  Standish Group Chaos Report 2013: „deliver less for less“  Nur 20% der Features werden oft verwendet, 50% nie / fast nie  Es gibt keinen Grund für große Projekte, große Projekte können auf 10% ihrer Größe reduziert werden  Jedes große IT Projekt kann in eine Reihe kleinerer Projekte aufgeteilt werden  Wie?  Analysiere nicht was sich der Fachbereich oder Endanwender... ... wünscht oder behauptet zu brauchen.  Analysiere die Probleme der Endanwender  Setze nie 100% der Anforderungen um, setze keine Anforderung 100% um - sondern nur die (Teile) mit höchstem Wert ► www.e-movimento.com, Sebastian Dietrich17
  16. 16. Vielen Dank für Ihre Aufmerksamkeit! Q&A[Sebastian Dietrich] Sebastian.Dietrich@e-movimento.com http://managing-java.blogspot.com ► www.e-movimento.com, Sebastian Dietrich18

Notas del editor

  • [Jones 1996] Applied Software Measurement, Capers Jones, 1996
    [Jones 1986] Programming Productivity, Capers Jones, 1986
    [Jones 1996] Software Defect-Removal Efficiency, Capers Jones, 1996
    [Shull 2002] What We Have Learned About Fighting Defects, Shull et al 2002
    [McConnell 2004] Code Complete, Steve McConnell 2004
    [Software Metrics 01] http://www.softwaremetrics.com/Articles/defects.htm
  • [Jones 01] , Capers Jones, 2001
    [Humphrey 89] Managing the software process, Watts S. Humphrey, 1989
    [Software Metrics 01] http://www.softwaremetrics.com/Articles/defects.htm
  • Weitere Infos:
    Assertion Coverage – Mutation Testing - https://www.slideshare.net/SebastianDietrich/mutationtesting-mit-pit
  • 6
  • 7
  • Weitere Infos:
    Testaufwand @ Wikipedia: https://de.wikipedia.org/wiki/Testaufwand
  • Literatur:
    Steve McConnell: Code Complete A Practical Handbook of Software Construction. 2. Auflage. Microsoft Press, 2004, ISBN 978-0-7356-1967-8
    Carnegie Mellon University's CyLab Sustainable Computing Consortium
  • Weitere Infos:
    Exploratives Testen @ Wikipedia: https://en.wikipedia.org/wiki/Exploratory_testing
    Itkonen, Juha; Mäntylä, Mika V. (2013-07-11). "Are test cases needed? Replicated comparison between exploratory and test-case-based software testing". Empirical Software Engineering. 19 (2): 303–342.
  • Weitere Infos:
    Review @ Wikipedia: https://de.wikipedia.org/wiki/Review_(Softwaretest)
  • 13
  • Weitere Infos:
    TDD @ Wikipedia: https://de.wikipedia.org/wiki/Testgetriebene_Entwicklung
  • Weitere Infos:
    BDD @ Wikipedia: https://de.wikipedia.org/wiki/Behavior_Driven_Development
  • Weitere Kontaktmöglichkeiten:
    Sebastian.Dietrich@e-movimento.com
    Skype: sebastian_dietrich
    http://de.wikipedia.org/wiki/Benutzer:Sebastian.Dietrich

×