Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Empfohlen
Empfohlen (20)
Did we test our changes? Test Gap Analysis with Teamscale (sitMUC 2016)
- 15. →
Hinweis der Redaktion
- Fehler treten bei langlebigen Software-Systemen besonders in den Bereichen auf, in denen viel geändert wurde. Testmanager verscuhen daher, diese Bereiche besonders gründlich zu testen. Unsere Beobachtung ist leider, dass das in der Praxis oft nicht gut klappt. Bei großen Projekten ist es aber nicht einfach, herauszufinden welche das sind, und ob die eigentlich getestet wurden. Insbesondere, wenn Entwicklung verteilt passiert. In diesem Vortrag stelle ich ein Verfahren zur Erkennung von ungetesteten Änderungen vor. Und Erfahrungen im praktischen Einsatz. Fragen gerne zwischendurch. Meinungen auch. Damit Sie Erfahrungen einordnen können, kurz zu meinem Hintergrund.
- Visualisierung, um das klarzumachen
- Besserer Ansatz: Erkennung von verschobenen Methoden, inkl. Umbenennung von Typen/Paketen etc. (Sack von Heuristiken, z.B: unveränderter Body, lokaler Name, Parameter(namen) etc.) z.B. wenn Methode in anderer Klasse gefunden, Analyse ob auch noch andere Methoden von der gleichen Umbenennung/Verschiebung betroffen sind. Verschobene Methoden werden hier als geändert erkannt, weil sich der Body (leicht) unterscheidet.
- Interessant: Mache Bereiche wurden überhaupt nicht getestet (insbesondere in neuem Code). Kommunikationsproblem offenbart: Haben falsche/unvollständige Testfälle erhalten.
- Wenn Fehlerfolgekosten zu gering, kein Nachtest erforderlich Fehlerwahrscheinlichkeit 0, wenn Ausführung unmöglich
- 100% Code Coverage garantiert das ja auch nicht.