What Makes Software Bugs Escape Testing? Evidence from a Large-Scale Empirical Study
Diese groß angelegte empirische Studie von über 14.000 Fehlern in C/C++- und Java-Systemen zeigt, dass Fehler nach dem Release vor allem durch evolutionäre und prozessbedingte Dynamiken in älteren, häufig modifizierten Komponenten getrieben werden und nicht allein durch die Code-Struktur, was nahelegt, dass Zuverlässigkeitsbemühungen gezielte Tests in diesen ausgereiften, stark wandelbaren Bereichen priorisieren sollten.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Stellen Sie sich vor, Sie sind ein Detektiv, der versucht, ein Rätsel zu lösen: Warum schleichen sich manche Softwarefehler an den Sicherheitswachen (den Testern) vorbei und treten erst auf, nachdem die Software der Öffentlichkeit übergeben wurde?
Die meisten früheren Forschungen konzentrierten sich auf die Fehler, die die Wachen abgefangen haben, bevor die Türen geöffnet wurden. Diese Arbeit argumentiert, dass dies so ist, als würde man nur die Kriminellen untersuchen, die am Flughafen erwischt wurden, während man diejenigen ignoriert, die erfolgreich durchgeschlüpft sind. Um die „Fluchtkünstler" zu verstehen, erstellten die Forscher eine riesige Datenbank mit über 14.000 Fehlern aus realer Software, die in C/C++ und Java geschrieben wurde. Sie verglichen die „abgefangenen" Fehler (vor der Veröffentlichung) mit den „entkommenen" Fehlern (nach der Veröffentlichung), um zu sehen, was sie unterscheidet.
Hier ist das, was sie herausfanden, erklärt durch einfache Analogien:
1. Es geht nicht um das „Aussehen" des Codes, sondern um seine „Geschichte"
Stellen Sie sich zwei Häuser vor.
- Haus A ist eine brandneue, einfache Hütte.
- Haus B ist eine alte Villa, die 50 Mal von 20 verschiedenen Handwerkern renoviert wurde, wobei einige Wände eingestürzt und andere hinzugefügt wurden.
Die Forscher stellten fest, dass die Fehler, die dem Test entkommen, sich normalerweise nicht in den „einfachen Hütten" (komplexer, unordentlicher Code) verstecken. Stattdessen verstecken sie sich fast immer in den „alten Villen" (älterer Code, der häufig geändert wurde).
- Die Analogie: Denken Sie an den Code wie an eine belebte Autobahn. Die Fehler, die entkommen, befinden sich normalerweise nicht in den brandneuen, leeren Spuren. Sie befinden sich in den alten, stark befahrenen Spuren, an denen Bauarbeiter seit Jahren arbeiten und die Schilder sowie den Belag verändern. Je mehr ein Codeabschnitt berührt wurde, je älter er ist und je mehr verschiedene Personen daran gearbeitet haben, desto wahrscheinlicher versteckt sich dort ein „Geisterfehler", der auf ein bestimmtes Verkehrsmuster wartet, um ihn auszulösen.
2. Die „Fluchtkünstler" sind schwerer zu fangen (und zu beheben)
Wenn ein Fehler vor der Veröffentlichung (in der Testphase) gefunden wird, ist es normalerweise wie das Finden eines Tippfehlers in einem Entwurf. Sie beheben ihn schnell, und er ist weg.
Aber wenn ein Fehler entkommt und nach der Veröffentlichung auftritt, ist es wie das Entdecken eines strukturellen Risses in einer Brücke, der nur erscheint, wenn ein bestimmter schwerer LKW zu einer bestimmten Tageszeit darüber fährt.
- Das Ergebnis: In C/C++ (der Sprache, die für Systeme wie Betriebssysteme und Spiel-Engines verwendet wird), dauert die Behebung dieser entkommenen Fehler viel länger und erfordert komplexere Änderungen als die Behebung von Fehlern vor der Veröffentlichung.
- Die Analogie: Die Behebung eines Fehlers vor der Veröffentlichung ist wie das Ersetzen eines kaputten Fliesens in einer Küche. Die Behebung eines Fehlers nach der Veröffentlichung in C/C++ ist wie der Versuch, einen tragenden Balken in einem Gebäude zu ersetzen, während noch Menschen darin wohnen. Es dauert länger, erfordert mehr Geschick und eine sorgfältigere Planung.
- Der Java-Unterschied: Interessanterweise war in Java (oft für Geschäftsanwendungen verwendet) der Unterschied in der Behebungszeit nicht so groß. Es ist, als wäre das „Gebäude" in Java leichter zu reparieren, vielleicht weil die Werkzeuge und Sicherheitsnetze (wie das automatische Speichermanagement) die Arbeit weniger gefährlich und chaotisch machen als in C/C++.
3. Die „Teamgröße" ändert sich nicht, aber die „Denkkraft" schon
Man könnte denken, dass die Behebung eines beängstigenden, entkommenen Fehlers eine ganze Armee von Menschen erfordert, um ihn zu lösen. Die Forscher stellten fest, dass dies nicht der Fall ist.
- Das Ergebnis: Die Anzahl der Personen, die an der Behebung eines Fehlers beteiligt sind, ist ungefähr gleich, egal ob er früh oder spät entdeckt wurde.
- Die Analogie: Egal, ob Sie einen tropfenden Wasserhahn (vor der Veröffentlichung) oder ein geplatztes Rohr im Keller (nach der Veröffentlichung) reparieren, Sie benötigen immer noch nur einen oder zwei Klempner. Der Unterschied besteht nicht darin, dass Sie mehr Leute benötigen; es ist vielmehr so, dass die Arbeit selbst schwieriger ist und länger dauert, bis diese gleichen Personen herausgefunden haben, was zu tun ist. Die „entkommenen" Fehler sind einfach verwirrender und tückischer zu diagnostizieren.
4. Die „Ausstrahlung" des Codes ändert sich
Die Forscher verwendeten Mathematik, um die „Persönlichkeit" des Codes zu betrachten.
- Das Ergebnis: Vor der Veröffentlichung ist die „Persönlichkeit" des Codes (seine Größe, Komplexität und Struktur) ziemlich vorhersehbar. Aber bei entkommenen Fehlern hat der Code eine chaotische, durcheinandergeratene Persönlichkeit.
- Die Analogie: Stellen Sie sich eine Bibliothek vor.
- Fehler vor der Veröffentlichung werden in Bereichen gefunden, in denen die Bücher nach Größe und Farbe ordentlich organisiert sind.
- Fehler nach der Veröffentlichung werden in Bereichen gefunden, in denen die Bücher über die Jahre von vielen verschiedenen Personen durcheinandergebracht, aufeinander gestapelt und verschoben wurden. Das „Chaos" der Geschichte ist es, das den Fehler versteckt, nicht die Tatsache, dass die Bücher groß oder klein sind.
Das Fazit
Die Arbeit kommt zu dem Schluss, dass wir nicht nur darauf schauen sollten, wie „kompliziert" ein Codeabschnitt im Moment aussieht, um Fehler zu finden. Stattdessen müssen wir auf seine Geschichte schauen.
Wenn ein Codeabschnitt alt ist, häufig geändert wurde und von vielen verschiedenen Personen berührt wurde, ist er ein primärer Versteckort für Fehler, die dem Test entkommen werden. Um diese „Fluchtkünstler" zu fangen, müssen Tester ihre Energie auf diese „alten, belebten Viertel" des Codes konzentrieren, anstatt nur die neuesten, am komplexesten aussehenden Teile zu überprüfen.
Kurz gesagt: Fehler, die dem Test entkommen, verstecken sich normalerweise nicht, weil der Code zu schwer zu lesen ist; sie verstecken sich, weil der Code eine lange, unordentliche Geschichte hat, die die Tester nicht vollständig simuliert haben.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.