Fehlerclustering im Quellcode

8

Es gibt viele Behauptungen über das Vorhandensein von Cluster von Fehlern oder Defekten. Eine einfache Suche zeigt mehrere Ergebnisse, zum Beispiel: 1 , 2 , 3 , 4 , 5 .

Alle angeführten Beweise sind jedoch anekdotisch, und ich konnte keine konkreten Daten finden, um dies zu belegen. Obwohl meine eigene Erfahrung diesen Behauptungen nicht widerspricht, lieben es die Leute, Muster zu sehen, selbst wenn es keine gibt (selbst eine gleichmäßige Verteilung der Fehler führt zu Clustern, und es ist möglicherweise einfacher, sich daran zu erinnern, wenn Sie 10 Fehler an einem Ort anstatt 10 beheben müssen nicht verwandte Dinge in der gesamten Codebasis).

Ich bin wirklich neugierig, ob dieses Phänomen tatsächlich existiert, aber ich konnte keine objektive oder sogar semi-objektive Quelle finden (wie in Tests, Experimenten, Studien usw.), die zeigen würde, dass Defektclustering tatsächlich vorkommt.

Natürlich kann ich die Hypothese des Fehlerclusters als gute Praxis annehmen (auch wenn sie falsch ist, tut sie nicht allzu weh). Auf der anderen Seite könnten konkrete Daten Aufschluss darüber geben, warum dies geschieht. Liegt es an diesen Tagen, dass man schreckliche Kopfschmerzen hat (aus welchem Grund auch immer)? Oder vielleicht, weil einige Teile des Codes nur schwer und andere einfach sind? Oder ist es vielleicht der Ort der Verantwortung dieser beiden Ingenieure, die sich nicht mögen?

Meine Frage: Gibt es tatsächlich einen Defektclustering-Effekt? Gibt es konkrete nicht anekdotische Daten, die am besten durch diese Hypothese erklärt werden können?

— dtldarek
quelle

Der Grund dafür ist, dass ein Fehler andere Fehler hervorrufen kann. Dies geschieht, weil der Code miteinander verknüpft ist. Während sich Tester wohl fühlen, wenn sie viele Fehler finden, wissen sie manchmal nicht, dass der Programmierer nur diesen einen Fehler beheben muss und alle anderen verschwunden sind.

— Kirie

Ich stimme @kirie hier zu, dass ein Fehler in einem Teil der Funktionalität normalerweise einen Kaskadeneffekt auf andere Teile der Funktionalität hat. Der Tester mag denken, dass es sich um verschiedene Fehler handelt, aber sie stammen alle aus dem einen Problem. Darüber hinaus sind Menschen gut darauf ausgelegt, Muster zu finden, weshalb wir dies in allem tun.

— Marshall Tigerus

Sehr selten habe ich einen Fehler, der irgendwo zufällige Informationen überschreibt. Mit dieser Art von Fehler im Quellcode könnte sich die Software auf unzählige mögliche Arten schlecht verhalten.

— Gnasher729

2

Ich denke, dies ist eine gültige Frage und möchte nicht, dass sie geschlossen wird, da das OP ausdrücklich nach "konkreten nicht anekdotischen Daten" gefragt hat. Die bisher gegebenen Antworten liefern dies jedoch nicht. Ich würde es lieber geschützt sehen und Antworten ohne Links zur Forschung abstimmen.

— Mattnz

@ gnasher729 Ich weiß nicht, welche Informationen Sie überschreiben, aber dies ist häufig der Fall, wenn Sie das DRY-Prinzip in einem frühen Stadium verwenden, in dem viele Funktionen noch nicht vollständig getestet wurden und bereits viele Male verwendet wurden.

— Kirie

3

Ich habe keine Daten zur Hand, aber ich bin mir ziemlich sicher, dass die Clustering-Hypothese wahr ist. Nach meiner besten Vermutung treten diese beiden Fälle mehr oder weniger häufig auf:

Ein Teil des Codes oder Algorithmus ist komplex (möglicherweise ist die Implementierung komplexer als nötig) und der ursprüngliche Programmierer hat aufgrund der Komplexität nicht vollständig verstanden, was sein Code tun könnte.
Der Code wurde nicht gut getestet

Und natürlich eine Kombination aus beidem. Das Testen ist schwierig, aber das Testen von komplexem Code ist um eine Größenordnung viel schwieriger. Und mit zunehmender Komplexität, insbesondere wenn Code nicht gut getestet wird, steigt meiner Erfahrung nach die Anzahl potenzieller Fehler in einem Code überproportional an.

Wenn Sie also mehrere Fehler in einem bestimmten Code finden, handelt es sich höchstwahrscheinlich um einen schlecht getesteten, komplexen Code, der Ihnen eine hohe Chance gibt, mehr davon in demselben Bereich zu finden.

— Doc Brown
quelle

2

Formale Studien wie diese gibt es in der Softwareentwicklung selten, wahrscheinlich weil das Programmieren (trotz seiner Verbindung mit Maschinen) in erster Linie ein menschliches Unterfangen ist, kein maschinelles.

Gestern habe ich einen Fehler in einer SQL-Anweisung behoben, der zwei SELECT-Anweisungen und eine UNION umfasste. Beide SELECTs gaben aufgrund eines einfachen Fehlers in einem JOIN das gleiche Ergebnis zurück. Bei der Behebung des Problems wurde jedoch ein weiterer Fehler aufgedeckt, der vom ersten Fehler maskiert wurde.

— Robert Harvey
quelle

2

Durch meine Erfahrung:

Clustering findet statt, wenn die Arbeit unterbrochen wird. Angenommen, jemand wird vom Projekt ausgeschlossen, sodass seine Arbeit nicht vollständig getestet oder vielleicht sogar abgeschlossen ist und / oder die Ergebnisse nicht vollständig verstanden werden.

Clustering tritt auch aufgrund des Problems "schlechter Programmierer" auf. Angenommen, 5 Personen haben an etwas gearbeitet und einer von ihnen war unterdurchschnittlich. Die Fehler werden mit seiner Arbeit verbunden sein.

Es gilt das Pareto-Prinzip (auch bekannt als 80/20-Regel). Etwa 80% der Auswirkungen sind auf 20% der Ursachen zurückzuführen. https://en.wikipedia.org/wiki/Pareto_principle Beachten Sie, dass diese Beobachtung vor Computern stammt.

— Dunkle Materie
quelle

0

Es gibt kein Paradoxon beim Bug-Clustering. Und unsere kognitiven Vorurteile entzünden die Flamme.

Gemäß der Normalverteilung zu einem bestimmten Zeitpunkt sind einige Teile der Codebasis wesentlich fehlerhafter als andere. Jeder neue Fehler wird eher im fehlerhaften Teil gefunden.
Diejenige, die Sie reparieren möchten, ist also bereits mit einer guten Chance auf eine Firma zum Scheitern verurteilt.

Es ist das gleiche wie "Unglück kommt nie einzeln".

— Vlad
quelle

1

Ich bin mir nicht sicher, ob die Normalverteilung es uns erlaubt, eine Schlussfolgerung zu ziehen, wie Sie vorschlagen. Ich gehe davon aus, dass wir die Fehlerdichte pro Codeeinheit analysieren. Bei jeder ungleichmäßigen Wahrscheinlichkeitsverteilung können wir sehen, dass einige Einheiten fehlerhafter sind als andere. Bei symmetrischen Verteilungen wie der Normalverteilung weist genau die Hälfte aller Module eine überdurchschnittliche Fehlerdichte auf! Das ist natürlich eine Folge der Annahme eines konstanten Risikos von Fehlern in allen Einheiten - aber ist das nicht das Gegenteil von dem, worum es in dieser Frage geht, dass Fehler mehr Fehler hervorrufen? Vielleicht habe ich diese Antwort falsch verstanden.

— Amon

"genau die Hälfte von ..." ja, aber es hat im aktuellen Kontext keinen Wert. Entschuldigung, ich habe dich nicht verstanden, Amon. Ich bin nicht mit der genauen Formulierung "Bugs züchten mehr Bugs" einverstanden. Mein Punkt ist, dass ein gefundener Fehler [mit einer Wahrscheinlichkeit, die wir nicht ignorieren können] dazu bestimmt ist, unter anderem zu sein.

— Vlad