rT(mi) =
f(mi)
f
p(mi)
p
 + 
f(mi)
f

Die Formel sieht komplizierter aus, als sie ist; gehen wir sie daher Stück für Stück durch. Berechnet werden soll rT(mi), also der Rank der Methode mi mit Hilfe des Tarantula-Lokators rT. Der Ausdruck f(mi) bezeichnet die Menge an fehlgeschlagenen Tests, welche die Methode mi aufrufen; f bezeichnet dagegen die Menge aller Tests, die fehlschlagen. Der Term f(mi) / f bezeichnet damit das Verhältnis zwischen den fehlschlagenden Tests, die mi aufrufen, und allen fehlschlagenden Tests. Analog dazu bezeichnet p(mi) die Menge an erfolgreichen Tests, die mi aufrufen und p die Menge aller erfolgreichen Tests.

Schauen wir uns dazu ein konkretes Beispiel an. Gegeben sei die folgende Abdeckungsmatrix, wobei die mit fi bezeichneten Spalten fehlschlagende und die mit pi bezeichneten Spalten erfolgreiche Tests kennzeichnen:

f1 f2 f3 f4 | p1 p2 p3
m1 1 |
m2 1 1 | 1
m3 1 | 1 1 1
m4 1 1 | 1 1 1
   
rT
1,00
0,60
0,20
0,33

Rechts neben der Tabelle sind die Verdächtigkeitswerte zu sehen, die durch den Tarantula-Lokator berechnet wurden. m1 wird nur durch einen einzigen (fehlschlagenden) Test aufgerufen, wodurch sich für die Berechnung der Verdächtigkeit folgende Formel ergibt:

rT(m1) =
1
4
= 1
0
3
 + 
1
4

Die Methode m2 wird von 2 fehlschlagenden und einem erfolgreichen Test aufgerufen, weswegen das Ranking folgendermaßen berechnet wird:

rT(m2) =
2
4
= 0,60
1
3
 + 
2
4

Anschließend werden die Methoden entsprechend ihres Rankings sortiert, in diesem Fall also m1, m2, m4 und als letztes m3. Der Tarantula-Lokator bewertet Methoden, die von vielen fehlschlagenden und wenig erfolgreichen Tests aufgerufen werden, als größere Kandidaten für einen Fehler als Methoden, die von wenigen fehlschlagenden und vielen erfolgreichen Tests aufgerufen werden. Für die systematische Fehlersuche würde man nun beginnen, zuerst m1 nach einem Fehler zu durchsuchen, da dies die Methode mit der größten Fehlerwahrscheinlichkeit ist. Sollte sich hier ein Fehler finden, ist die Suche beendet; ansonsten würde mit m2 fortgefahren werden, dann m4 und als letztes m3 (wo dann hoffentlich ein Fehler gefunden wird). Eine Voraussetzung für den Einsatz von Tarantula ist, dass wenigstens ein Test fehlschlägt und wenigstens ein Test erfolgreich durchläuft – ansonsten würde sich in der Formel eine Division durch 0 ergeben, was ja nicht im Sinne der Mathematik ist.

Neben Tarantula gibt es noch weitere (und bessere) Lokatoren, durch welche die getesteten Methoden in ein Ranking überführt werden können. Die meisten von ihnen arbeiten über Formeln, die auf die ein oder andere Weise das Verhältnis von fehlschlagenden zu erfolgreichen Tests, die eine Methode ausführen, bewerten. Ein Problem ist allerdings allen gemein (darin liegt wohl auch begründet, dass die Fehlerlokalisierung nach wie vor ein eher akademisch bearbeitetes Thema ist): Bei hinreichend großen Programmen müssen sehr viele Methoden entsprechend ihres Rankings untersucht werden, bis ein Fehler gefunden wird – zu viele, um in der Praxis gegen den “intuitiven Ansatz” (d. h. einen fehlschlagenden Test debuggen und den Fehler auf Grundlage der Kenntnisse über das Programm suchen) zu bestehen.

Weiterhin ist problematisch, dass dieser Ansatz nur für das Finden eines einzelnen Fehlers geeignet ist. Warum das so ist und welche Lösung es hierfür gibt, werde ich im nächsten Teil der Serie beleuchten.

1 / 2

Kommentare (12)

  1. #1 Eckbert
    Juli 23, 2017

    Interessantes Thema und gute Erklärung! Weiter so! 🙂

  2. #2 tomtoo
    Juli 23, 2017

    Nicht böse gemeint ,aber gerade wurde ein neues OS geprogt und die Fehler wurden nur über anwenderfeedback beseitigt.

    Aber die anderen sind immerhin schon bei 0.1 ihrer Unittests. Das wird !

    • #3 Marcus Frenkel
      Juli 23, 2017

      @tomtoo: So ganz kann ich mit dem Kommentar jetzt nichts anfangen…etwas Erklärung vielleicht?

  3. #4 tomtoo
    Juli 23, 2017

    Sry ist so rausgerutscht. Schöne Theorie. Unittests kosten Zeit. Prog. Aufwand auch mit Tools. Ich kenne mich aber mit hoch optimierten OOP Systemen nicht aus. Also beim Change Management im regulierten Umfeld usw. Alltag war anwendertest.Der unterschreibt. Und zahlt für Weiterentwicklung. Sieht der nix. Keine Kohle und wenn das System noch so schön ist. Aber gut ist ja nur eigene Erfahrung.

  4. #5 tomtoo
    Juli 23, 2017

    Entschuldige ist so meine Art. Nicht böse gemeint.
    Hab ich sowas wie ein reines SAP System ist ja noch vorstellbar , die Sinnhaftigkeit von Unittests. Aber gehts mal über mehr Welten z. B. SAP ..SQL.. .DataTransformation…Analisys..Web. Wie soll das noch gehen ?
    Sollte keine Werbung sein. Aber Alltag halt.

  5. #6 tomtoo
    Juli 23, 2017

    Noch ein Nachtrag sry. Hatten mal einen wunderschönen Fehler einer CRM Software. Hatt 24.00 Uhr geliefert. Streikt der SQL Server beim INSERT : ) da wär ein Unittest super gewesen.

  6. #7 Dwon
    Juli 24, 2017

    Fehlerlokalisierung ist in Java glücklicherweise einfacher. Mit dem StackTrace (falls vorhanden) die Methoden abklappern. Und ein vernünftiges Logging dazu, schon kann man sehr stark eingrenzen wo der Fehler liegt.
    Oder man schaut sich im Debug-Modus live an welche Werte die Variablen gerade haben.

    Gibt es zur obigen Methode auch ein Praxisbeispiel? Oder geht es um große Systeme, die aus verschiedener Software bestehen?

    • #8 Marcus Frenkel
      Juli 24, 2017

      Unabhängig von der Programmgröße: Der StackTrace hilft nur bedingt, da er immer noch erfordert, dass mehrere Methoden betrachtet werden, bis der Fehler gefunden wird. Die Idee der Fehlerlokalisierung ist, dass idealerweise durch den Lokator genau die Methode “berechnet” wird, welche den Fehler enthält, der Programmierer also überhaupt nicht nach einer fehlerhaften Methode (oder einem fehlerhaften Statement; das ganze kann ja auch auf Statementebene durchgeführt werden) suchen muss.

  7. #9 Robert
    Juli 24, 2017

    tomtoo,
    …..Fehlersuche,
    ganz teuflisch wird es, wenn man den Fehler lokalisiert hat aber nicht weiß, warum der Programmteil nicht so arbeitet, wie er soll.
    Aus meinem kleinen Erfahrungsschatz kann ich nur sagen, manchmal geht es schneller, wenn man ein Programmteil ganz neu schreibt, anders schreibt, als zu debuggen.

  8. #10 tomtoo
    Juli 24, 2017

    @Robert
    Nö richtig teuflisch ist zu sehen das was nicht stimmt. Es im Hirn aber nicht klick macht. Wie die besagten 24:00 ; )

  9. #11 Robert
    Juli 25, 2017

    tomtoo,
    …..es nicht klick macht,
    das meine ich doch, das frisst doch die Zeit.

    Dwon,
    …..Debugger,
    die sind eine herrliche Sache. Bei Syntaxfehlern geht es einfach prima. Aber wenn du einen logischen Fehler im Programm hast, dann hilft dir kein Schwein.
    Deswegen habe ich einmal ein ganzes Programm umstrukturieren müssen.

  10. #12 Laie
    August 5, 2017

    Derzeit sucht man Softwarefehler bei VW, die gute Abgase ausgaben, obwohl die Werte schlecht waren. Anwenderfeedback reicht da nicht aus, die mussten erst verklagt werden, damit die Feedbackschleife so einigermassen funktioniert. Vielleicht sind es auch Fachkräfte die mängeln?