💻 computer science

What Makes Software Bugs Escape Testing? Evidence from a Large-Scale Empirical Study

Deze grootschalige empirische studie van meer dan 14.000 defecten in C/C++- en Java-systemen onthult dat bugs na de release voornamelijk worden veroorzaakt door evolutionaire en procesdynamiek in oudere, vaak gewijzigde componenten en niet alleen door de codestructuur, wat suggereert dat betrouwbaarheidsinspanningen gericht moeten worden op gerichte tests in deze rijpe, hoog-volatiliteitsgebieden.

Oorspronkelijke auteurs: Domenico Cotroneo, Giuseppe De Rosa, Cristina Improta, Benedetta Gaia Varriale

Gepubliceerd 2026-04-30

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Domenico Cotroneo, Giuseppe De Rosa, Cristina Improta, Benedetta Gaia Varriale

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een detective bent die een mysterie probeert op te lossen: Waarom glippen sommige softwarebugs langs de bewakers (de testers) en komen ze pas naar voren nadat de software aan het publiek is vrijgegeven?

Het merendeel van het eerdere onderzoek richtte zich op de bugs die de bewakers vingen voordat de deuren opengingen. Dit artikel betoogt dat dit vergelijkbaar is met het bestuderen van alleen de criminelen die op de luchthaven werden gepakt, terwijl je degenen negeert die er succesvol doorheen slopen. Om de "ontsnappingskunstenaars" te begrijpen, bouwden de onderzoekers een enorme database van meer dan 14.000 bugs uit real-world software geschreven in C/C++ en Java. Ze vergeleken de "gevangen" bugs (voor-release) met de "ontsnapte" bugs (na-release) om te zien wat hen onderscheidt.

Hier is wat ze vonden, uitgelegd via eenvoudige analogieën:

1. Het gaat niet om de "uitstraling" van de code, maar om zijn "geschiedenis"

Stel je twee huizen voor.

Huis A is een gloednieuwe, eenvoudige schuur.
Huis B is een oud herenhuis dat 50 keer is gerenoveerd door 20 verschillende aannemers, waarbij sommige muren zijn gesloopt en andere zijn toegevoegd.

De onderzoekers ontdekten dat de bugs die de tests ontglippen, meestal niet schuilen in de "eenvoudige schuren" (complexe, rommelige code). In plaats daarvan verstoppen ze zich bijna altijd in de "oude herenhuizen" (oude code die vaak is gewijzigd).

De Analogie: Denk aan de code als een drukke snelweg. De bugs die ontsnappen, zitten meestal niet in de gloednieuwe, lege rijbanen. Ze zitten in de oude, zwaar belaste rijbanen waar bouwteams al jaren werken, waarbij ze borden en asfalt veranderen. Hoe meer een stuk code is aangeraakt, hoe ouder het is, en hoe meer verschillende mensen er aan hebben gewerkt, hoe waarschijnlijker het is dat er een "spookbug" schuilt die wacht op een specifiek verkeerspatroon om te worden geactiveerd.

2. De "ontsnappingskunstenaars" zijn moeilijker te vangen (en te repareren)

Wanneer een bug voor de release wordt gevonden (in de testfase), is het meestal als het vinden van een typefout in een concept. Je repareert het snel en het is weg.

Maar wanneer een bug ontsnapt en na de release naar voren komt, is het als het vinden van een structurele scheur in een brug die alleen zichtbaar wordt wanneer een specifieke zware vrachtwagen op een bepaald tijdstip van de dag eroverheen rijdt.

De Bevinding: In C/C++ (de taal die wordt gebruikt voor systemen zoals besturingssystemen en game-engines) duurt het repareren van deze ontsnapte bugs veel langer en vereist het complexere wijzigingen dan het repareren van pre-release bugs.
De Analogie: Het repareren van een pre-release bug is als het vervangen van een gebroken tegel in een keuken. Het repareren van een post-release bug in C/C++ is als het proberen een dragende balk in een gebouw te vervangen terwijl er nog mensen in wonen. Het kost meer tijd, meer vaardigheid en meer zorgvuldige planning.
Het Java-verschil: Interessant genoeg was het verschil in reparatietijd in Java (vaak gebruikt voor zakelijke applicaties) niet zo groot. Het is alsof het "gebouw" in Java makkelijker te repareren is, misschien omdat de tools en veiligheidsnetten (zoals automatisch geheugenbeheer) de taak minder gevaarlijk en chaotisch maken dan in C/C++.

3. De "teamgrootte" verandert niet, maar de "breinkracht" wel

Je zou denken dat het oplossen van een angstaanjagende, ontsnapte bug een heel leger mensen vereist. De onderzoekers ontdekten dat dit niet waar is.

De Bevinding: Het aantal mensen dat betrokken is bij het repareren van een bug is ongeveer hetzelfde, of het nu vroeg of laat wordt gevonden.
De Analogie: Of je nu een lekkende kraan repareert (pre-release) of een gebarsten pijp in de kelder (post-release), je hebt nog steeds maar één of twee loodgieters nodig. Het verschil is niet dat je meer mensen nodig hebt; het is dat de taak zelf moeilijker is en langer duurt voor diezelfde mensen om uit te zoeken. De "ontsnapte" bugs zijn gewoon verwarrender en lastiger te diagnosticeren.

4. De "sfeer" van de code verandert

De onderzoekers gebruikten wiskunde om naar de "persoonlijkheid" van de code te kijken.

De Bevinding: Voor de release is de "persoonlijkheid" van de code (zijn grootte, complexiteit en structuur) vrij voorspelbaar. Maar voor ontsnapte bugs heeft de code een chaotische, door elkaar gehaalde persoonlijkheid.
De Analogie: Stel je een bibliotheek voor.
- Pre-release bugs worden gevonden in secties waar de boeken netjes zijn gerangschikt op grootte en kleur.
- Post-release bugs worden gevonden in secties waar de boeken door elkaar zijn geschud, op elkaar zijn gestapeld en door veel verschillende mensen over vele jaren zijn verplaatst. De "chaos" van de geschiedenis is wat de bug verbergt, niet het feit dat de boeken groot of klein zijn.

De Conclusie

Het artikel concludeert dat we niet alleen moeten kijken naar hoe "complexe" een stuk code er op dit moment uitziet om bugs te vinden. In plaats daarvan moeten we kijken naar zijn geschiedenis.

Als een stuk code oud is, veel is gewijzigd en is aangeraakt door veel verschillende mensen, is het een ideale schuilplaats voor bugs die de tests zullen ontglippen. Om deze "ontsnappingskunstenaars" te vangen, moeten testers hun energie richten op deze "oude, drukke buurten" van de code, in plaats van alleen de nieuwste, meest complex ogende delen te controleren.

Kortom: Bugs die de tests ontglippen, verstoppen zich meestal niet omdat de code te moeilijk te lezen is; ze verstoppen zich omdat de code een lange, rommelige geschiedenis heeft die de testers niet volledig hebben gesimuleerd.

1. Probleemstelling

De betrouwbaarheid van software wordt vaak ondermijnd door residuele defecten (bugs na release) die strenge pre-release testen ontlopen en zich pas in productieomgevingen manifesteren. Hoewel bestaand onderzoek pre-release defecten uitgebreid in kaart brengt, bestaat er een aanzienlijke lacune in het begrijpen van de specifieke eigenschappen die ervoor zorgen dat bepaalde bugs onopgemerkt blijven.

De Lacune: Huidige testtools en defectvoorspellingsmodellen worden vaak geoptimaliseerd op basis van 'survivorship bias' (overlevingsbias); ze leren van bugs die gemakkelijk worden gevangen, in plaats van van diegenen die ontsnappen.
De Urgentie: Met de verschuiving van de industrie naar AI-ondersteunde ontwikkeling wordt voorspeld dat het risico op onopgemerkte bugs in productie zal stijgen. Het begrijpen van de onderscheidende kenmerken van residuale fouten is cruciaal voor het ontwerpen van betere teststrategieën en processen voor betrouwbaarheidsengineering.

2. Methodologie

De auteurs voerden een grootschalige empirische studie uit met C/C++ en Java-systemen om pre-release (niet-residuale) en post-release (residuale) defecten te karakteriseren en te vergelijken.

A. Datasetconstructie

Bron: Real-world open-source projecten gehost op GitHub.
Schaal: De studie onderzocht meer dan 200.000 kandidaten voor bugfixes, die werden gefilterd tot een gebalanceerde dataset van ongeveer 7.128 bevestigde defecten (4.010 C/C++ en 3.118 Java).
Granulariteit: De analyse werd uitgevoerd op functie-/methodniveau. Voor elk defect reconstrueerden de auteurs de specifieke 'defecte' functie (voor fix) en de 'gefixte' functie (na fix) met behulp van git diff en AST-parsing (via Tree-sitter).
Classificatieheuristiek: Om residuale van niet-residuale defecten te onderscheiden, ontwikkelden de auteurs een nieuwe multi-signaalheuristiek die de volgende elementen combineert:
1. Issue-labels: (bijv. bug, regression versus feature).
2. Tekst van het issue-bericht: Het detecteren van patronen zoals 'stappen om te reproduceren' (door gebruiker gerapporteerd/residuaal) versus 'CI-testfalen' (intern/niet-residuaal).
3. Identiteit van de rapporteur: Externe gebruikers (waarschijnlijk residuaal) versus interne beheerders (waarschijnlijk niet-residuaal).
- Validatie: Een handmatige review van 400 samples bevestigde een overeenkomstpercentage van 97% tussen de heuristiek en expertoordeel.

B. Metrische Extractie

De studie extraheerde 44 softwaremetrieken ingedeeld in drie groepen om de defecten te profileren:

Productmetrieken (Structureel): Complexiteit (Halstead, Cyclomatic), Grootte (LOC, statements), Koppeling (Fan-in/out) en Documentatie.
Procesmetrieken (Evolutionair): Code-churn, commitgeschiedenis, leeftijd van de functie, aantal verschillende auteurs en bugdichtheid.
Statistische Metrieken: Code-natuurlijkheid (Entropie) met behulp van een n-gram-taalmodel (KenLM) om te meten hoe 'voorspelbaar' of 'natuurlijk' de code is in vergelijking met een baseline van correcte code.

C. Analysetechnieken

Clustering & PCA: Gebruikt om correlatiestructuren tussen metrieken te identificeren en de dimensionaliteit te reduceren om dominante factoren te vinden.
Statistische Toetsing: Kolmogorov-Smirnov (KS)-toetsen en Cliff's $\delta$ -effectgroottes om te bepalen of de verdelingen van metrieken significant verschillen tussen residuale en niet-residuale defecten.
Inspanningsanalyse: Vergelijking van 'Tijd tot sluiting' en 'Aantal gebruikers tot sluiting' voor issues, en analyse van de complexiteit van de vereiste codeveranderingen ( $\Delta$ -metrieken) om de bugs te fixen.

3. Belangrijkste Bijdragen

Methodologie: Een robuuste pijplijn voor het verzamelen, classificeren en reconstrueren van residuale fouten op functieniveau over heterogene systemen heen.
Datasets: Twee grootschalige, gebalanceerde datasets (C/C++ en Java) verrijkt met product-, proces- en statistische metrieken, publiek vrijgegeven voor reproduceerbaarheid.
Karakterisering: Een uitgebreide empirische evaluatie die aantoont dat residuale defecten niet alleen 'moeilijker te vinden' zijn, maar fundamenteel verschillen in hun evolutionaire en procesdynamiek in vergelijking met pre-release defecten.

4. Belangrijkste Resultaten en Bevindingen

Bevinding 1: Divergente Metriekcorrelaties

Hoewel beide defecttypes afhankelijk zijn van vergelijkbare metriekfamilies, verschillen hun interne correlatiestructuren:

Pre-release defecten: Metrieken clusteren strak rond structurele grootte en eenvoudige churn.
Residuale defecten: Vertonen meer heterogene en instabiele metriekprofielen. Bij residuale fouten lossen structurele metrieken (zoals grootte) zich los van complexiteitsmaten, en verschuiven procesmetrieken van eenvoudige 'churn' naar een complexe mix van koppeling, leeftijd en commitgeschiedenis.

Bevinding 2: Proces en Geschiedenis Domineren boven Structuur

Statistische analyse (KS-toetsen en effectgroottes) toonde aan dat proces- en historische metrieken de sterkste discriminatoren zijn, terwijl traditionele structurele metrieken een secundaire rol spelen (vooral in Java).

Belangrijkste Differentiatoren: Residuale defecten komen significant vaker voor in:
- Oudere codecomponenten.
- Gebieden met hoge churn (frequent gewijzigd).
- Componenten met hoge koppeling en verspreide auteurschap.
- Gebieden met een hoge historische bugdichtheid.
Taalnuance: In C/C++ toonden structurele metrieken (zoals LOC en comments) enige differentiatie. In Java waren structurele metrieken tussen de twee groepen bijna niet te onderscheiden; alleen proces-/geschiedenismetrieken waren van belang.

Bevinding 3: Hogere Fixinspanning in C/C++

Tijd tot Fix: Post-release defecten duren aanzienlijk langer om op te lossen.
- C/C++: De mediane tijd steeg van 14 dagen (pre-release) naar 25 dagen (post-release). De modus verschuifde van 0 dagen naar 84 dagen, wat wijst op een lange staart van moeilijke, omgevingsspecifieke fouten.
- Java: De mediane tijd steeg van 14 naar 28 dagen, maar de modus bleef identiek, wat wijst op een meer uniform (hoewel nog steeds vertraagd) oplosproces.
Complexiteit: Fixes voor residuale defecten in C/C++ vereisten iets grotere codeveranderingen en hogere cognitieve complexiteit (Halstead-metrieken). In Java was het verschil in fixcomplexiteit minimaal.
Samenwerking: Het aantal betrokken bijdragers bleef vergelijkbaar voor beide typen, wat suggereert dat de extra inspanning technisch is (diagnose van complexe interacties) en niet organisatorisch.

5. Betekenis en Implicaties

Verschuiving in Teststrategie: De studie pleit ervoor dat betrouwbaarheidsengineering verder moet gaan dan statische codeanalyse (grootte/complexiteit) en prioriteit moet geven aan evolutionair risicoprofileren. Testinspanningen moeten gericht zijn op rijpe, hoog-churn en sterk gekoppelde componenten, aangezien dit de primaire broedplaatsen zijn voor residuale defecten.
Defectvoorspellingsmodellen: Toekomstige modellen moeten onderscheid maken tussen 'defectvoorkomen' en 'defectontsnapping'. Modellen die productierisico voorspellen, moeten proceskenmerken (leeftijd, churn, auteurschap) zwaarder wegen dan structurele kenmerken.
AI-ondersteunde Ontwikkeling: Aangezien AI code genereert die lokaal correct kan zijn maar historische of omgevingsaannames schendt, zal het risico op residuale defecten in complexe, evoluerende codebases waarschijnlijk toenemen. De bevindingen suggereren dat evolutiebewuste verificatie cruciaal is voor de toekomst van softwarebetrouwbaarheid.
Praktische Toepassing: CI/CD-pijplijnen en release-dashboards moeten evolutionaire signalen (bijv. "hoge churn + hoge leeftijd") integreren als eersteklas betrouwbaarheidsindicatoren, naast traditionele dekkingmetrieken.

Conclusie

Residuale defecten zijn niet louter het resultaat van codecomplexiteit; ze zijn een fenomeen van evolutionaire dynamiek. Ze ontstaan in codegebieden waar historische aannames, omgevingsinteracties en complexe verandergeschiedenissen condities creëren die standaardtesten niet kunnen repliceren. Het aanpakken ervan vereist een verschuiving van statische codeinspectie naar dynamische, geschiedenisbewuste betrouwbaarheidsengineering.