📊 statistics

An Upper Bound on the Probability That a User Encounters an Undiscovered Defect

Dieses Paper schlägt eine distributionsfreie obere Schranke für die Wahrscheinlichkeit vor, mit der ein Nutzer auf einen unentdeckten Softwarefehler stößt, und zeigt auf, dass der Anteil der Defekte, die während des Beta-Testings genau einmal gemeldet wurden ( $s/n$ ), als konservative, modellunabhängige Schätzung zur Eignung für Release-Entscheidungen dient.

Ursprüngliche Autoren: Carlos M. Hernández-Suárez, Karla Hernández-Cuevas

Veröffentlicht 2026-07-21

📖 7 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Carlos M. Hernández-Suárez, Karla Hernández-Cuevas

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

Die große Fehlersuche: Warum das Zählen von Fehlern nicht ausreicht

Stellen Sie sich vor, Sie sind ein Koch, der kurz davor steht, ein riesiges Bankett für tausende Gäste zu servieren. Bevor Sie die Türen öffnen, haben Sie ein Team von Geschmackstestern (Ihre Beta-Tester), die das Essen probiert und gerufen haben: „Hey, diese Suppe ist zu salzig!“ oder „Da ist ein Stein in diesem Kuchen!“ Sie beheben die Probleme, die sie gefunden haben. Aber hier kommt die beängstigende Frage: Wenn Sie jetzt die Türen öffnen, wie hoch ist die Wahrscheinlichkeit, dass ein zufälliger Gast, der hereinkommt, in einen Stein beißt, den Sie übersehen haben?

Dies ist der Kern eines Problems in der Informatik, das „Software-Zuverlässigkeit“ genannt wird. Jahrzehntelang haben Entwickler versucht, dies durch Zählen zu beantworten. Sie fragen: „Wie viele Steine liegen noch in der Küche?“ Sie nutzen komplexe Mathematik, um die Gesamtzahl der verborgenen Fehler zu erraten. Aber es gibt einen Haken: Zu wissen, dass noch zehn Steine übrig sind, sagt einem nicht, ob sie alle hinten im Vorratsschrank liegen (wo vielleicht nur eine Person sie finden würde) oder ob ein riesiger Felsbrocken direkt vor der Vordertür liegt (wo jeder darüber stolpern wird). Die alten Methoden bleiben oft dabei stecken, Steine zu zählen, und ignorieren dabei, dass manche Steine viel gefährlicher sind als andere, weil von der Position her.

Um dies zu lösen, müssen wir aufhören, Steine zu zählen, und anfangen, Menschen zu zählen. Wir müssen wissen, wie hoch die Wahrscheinlichkeit ist, dass eine zufällige Person auf ein Problem stößt. Diese Arbeit befasst sich mit genau dieser Frage: Anstatt zu fragen „Wie viele Bugs sind noch übrig?“, fragt sie: „Wie hoch ist die Chance, dass ein Nutzer auf einen Bug stößt, den er noch nie gesehen hat?“ Es stellt sich heraus, dass es einen überraschend einfachen Weg gibt, dies zu erraten, indem man einen Trick anwendet, der betrachtet, wie oft Tester denselben Fehler mehr als einmal gefunden haben.

Die große Idee des Papers: Die „Einmalige-Wunder“-Regel

Die Autoren, Carlos M. Hernández-Suárez und Karla Hernández-Cuevas, schlagen eine clevere Abkürzung vor. Sie schlagen vor, dass man, um das Risiko zu erraten, mit einem verborgenen Bug aufzustoßen, nicht die Gesamtzahl der Bugs kennen muss, nicht wissen muss, wie die Software gebaut ist, oder sogar, wie viele Menschen sie benutzen. Man muss nur seine Fehlermeldungen betrachten und etwas ganz Bestimmtes zählen: die Bugs, die genau einmal gemeldet wurden.

Lassen Sie uns eine Analogie verwenden. Stellen Sie sich vor, Sie sind ein Detektiv, der versucht herauszufinden, wie viele verschiedene Arten von Alien-Spezies Ihren Ort besuchen. Sie haben ein Logbuch der Sichtungen.

Wenn Sie „Zog“ 50 Mal sehen, wissen Sie, dass Zog ein häufiger Alien ist.
Wenn Sie „Xyl“ 3 Mal sehen, ist Xyl etwas seltener.
Aber wenn Sie „Blorp“ genau einmal sehen und nie wieder, was sagt Ihnen das?

Das Paper argumentt, dass diese „Blorps“ – die Bugs, die genau einmal gesehen wurden – der Schlüssel sind. Sie bezeichnen den Anteil dieser Einzelsichtungen ( $s$ ) an der Gesamtzahl der Sichtungen ( $n$ ) als eine „konservative obere Schranke“. Auf Deutsch gesagt: Der Prozentsatz der Bugs, die genau einmal gemeldet wurden, ist eine sichere, „Worst-Case“-Schätzung für den Prozentsatz der Nutzer, die auf einen brandneuen, bisher ungesehenen Bug stoßen werden.

Warum das funktioniert (Die „Geschlossene-Tür“-Logik)

Sie fragen sich vielleicht: „Was ist, wenn Bugs hinter anderen Bugs versteckt sind? Wie ein Geheimzimmer hinter einer verschlossenen Tür?“ Die Autoren gehen dem mit einem brillanten Stück Logik nach.

Stellen Sie sich vor, die Software ist ein riesiges Herrenhaus mit vielen Zimmern. Einige Bugs sind im Flur (leicht zu finden). Einige sind in einem Geheimzimmer hinter einer verschlossenen Tür (schwer zu finden).

Wenn ein Nutzer die verschlossene Tür trifft (einen Bug), kann er nicht in das Geheimzimmer dahinter gelangen.
Daher ist die Anzahl der Menschen, die das Geheimzimmer erreichen können, immer kleiner oder gleich der Anzahl der Menschen, die die verschlossene Tür treffen.

Die Autoren zeigen, dass man aufgrund dieser „verschachtelten“ Struktur keine Sorge wegen der verborgenen Zimmer haben muss. Die „Einmal-Meldungen“, die Sie tatsächlich gefunden haben, berücksichtigen bereits das Risiko der verborgenen Bugs. Wenn ein Bug einmal gemeldet wird, fungiert er als „Tür“, die das Risiko von allem dahinter begrenzt. Also reicht das Zählen der Einzelmeldungen aus, um das ganze Haus abzudecken.

Was sie getan und was sie gefunden haben

Die Autoren haben nicht nur geraten; sie haben ein mathematisches Modell namens „Canonical Form“ gebaut (denken Sie an eine spezielle Art von Urne oder Glas voller farbiger Kugeln). Sie haben mathematisch bewiesen, dass, wenn man seine Fehlermeldungen wie das Ziehen von Kugeln aus dieser Urne behandelt, der Anteil der Kugeln, die nur einmal vorkommen ( $s/n$ ), die exakte Maximum-Likelihood-Schätzung für die „fehlende Masse“ (die ungesehenen Bugs) ist.

Entscheidend ist, dass sie zeigten, dass diese Schätzung konservativ ist. Das bedeutet, dass sie das Risiko eher überschätzt als unterschätzt.

Warum das gut ist: Wenn Sie ein Entwickler sind, der entscheidet, ob er Software veröffentlicht, wollen Sie auf der sicheren Seite sein. Wenn die Mathematik sagt: „Es gibt eine 5%-ige Chance für einen Bug“, und die echte Chance liegt bei 3 %, sind Sie sicher. Wenn die Mathematik 3 % sagte und die echte Chance 5 % war, wären Sie in Schwierigkeiten. Diese Methode stellt sicher, dass Sie immer auf der sicheren Seite sind und zur Vorsicht neigen.

Sie haben diese Idee mithilfe von Computersimulationen getestet (indem sie künstliche Populationen von Bugs mit bekannten Antworten erzeugten).

In einem Test mit 20 Bugs fanden sie, dass sie, während sie „mehr Nutzer testeten“ (Erhöhung der Stichprobengröße von 25 auf 400), ihre Schätzung ( $s/n$ ) immer höher oder gleich der tatsächlichen Anzahl der ungesehenen Bugs war.
Zum Beispiel: Mit 100 Testnutzern lag das wahre ungesehene Risiko bei 0,0059 und ihre Schätzung lag bei 0,0063. Die Schätzung war etwas zu hoch (konservativ), aber niemals zu niedrig.

Was dies NICHT ist (Die Regeln des Spiels)

Das Paper ist sehr deutlich darüber, was diese Methode nicht kann, und es ist wichtig, dies richtig zu verstehen:

Es ist NICHT zum Zählen von Bugs gedacht. Es sagt Ihnen nicht: „Es sind noch 50 Bugs übrig.“ Es sagt Ihnen: „Es besteht eine 2%-ige Chance, dass ein Nutzer auf einen Bug stößt.“
Es ist NICHT für öffentliche Bug-Listen gedacht. Die Autoren schließen die Verwendung auf Standard-Bug-Datenbanken (wie sie im Internet zu finden sind) explizit aus. Warum? Weil in diesen Listen ein Bug meistens nur einmal von einer Person gemeldet wird, selbst wenn 1.000 Leute ihn gefunden haben. Der „Zähler“ geht verloren. Um diese Methode anzuwenden, benötigen Sie Daten, die besagen: „Dieser Bug wurde von 50 verschiedenen Nutzern aufgerufen“, und nicht nur „Dieser Bug wurde gemeldet“.
Es ist KEINE Kristallkugel für die Zukunft. Es liefert eine Momentaufnahme des Risikos jetzt gerade. Wenn Sie die Bugs beheben und erneut testen, müssen Sie die Berechnung neu durchführen.

Das Fazit

Dieses Paper bietet eine direkte, schnörkellose Antwort auf die Entscheidung zur Veröffentlichung. Es sagt: „Machen Sie sich keine Sorgen darüber, wie viele Bugs in der Dunkelheit lauern. Schauen Sie einfach, wie viele Bugs Ihre Tester genau einmal gefunden haben. Diese Zahl, geteilt durch Ihre Gesamtzahl an Tests, ist Ihre sichere, obere Schätzung dafür, wie viele Nutzer auf einen Bug stoßen werden, den Sie übersehen haben.“

Es ist ein Werkzeug, das eine komplexe, beängstigende Ungewissheit in eine einfache, sichere Zahl verwandelt und sicherstellt, dass Entwickler, wenn Software ausgeliefert wird, eine klare, konservative Sicht auf das Risiko für ihre Nutzer haben.

Technische Zusammenfassung: Eine obere Schranke für die Wahrscheinlichkeit, dass ein Benutzer auf einen unentdeckten Defekt stößt

Problemstellung
Die Arbeit adressiert eine kritische Entscheidungslücke im Software-Release-Management: die Bestimmung der Wahrscheinlichkeit, mit der ein Benutzer eines veröffentlichten Produkts auf einen Defekt stößt, der während des Beta-Tests nicht entdeckt wurde. Die bestehende Literatur konzentriert sich primär auf die Schätzung der Anzahl verbleibender Defekte (unter Verwendung von Modellen zum Wachstum der Softwarezuverlässigkeit oder Capture-Recapture-Methoden) oder auf die Abdeckung (Coverage) ungesehener Klassen im Kontext des Fuzzings. Diese Ansätze versäumen es jedoch, die Release-Frage direkt zu beantworten, weil:

Zahlbasierte Methoden ein „Operational Profile“ (die Verteilung der Softwarenutzung im Feld) erfordern, um eine Defektanzahl in eine benutzerseitige Ausfallwahrscheinlichkeit umzuwandeln. Dieses Profil ist äußerst schwierig zu schätzen.
Coverage-Methoden (z. B. Good-Turing) wurden auf Software-Fuzzing angewendet, wobei der „Sampler“ eine Maschine ist, die Eingaben generiert. In diesem Kontext spiegelt die Häufigkeit eines Bugs die Zufälligkeit der Maschine wider, nicht die Häufigkeit, mit der menschliche Benutzer ihm begegnen.
Strukturelle Komplexität: Software ist keine flache, austauschbare Population wie biologische Arten; sie besitzt eine Erreichbarkeitsstruktur (Bäume oder DAGs), in der einige Defekte hinter anderen „gegatet“ sind. Bestehende Methoden berücksichtigen nicht, wie diese Architektur die Wahrscheinlichkeit beeinflusst, mit der ein Benutzer einen spezifischen verborgenen Defekt findet.

Die Autoren argumentieren, dass die Release-Entscheidung eine direkte Schätzung der nutzergewichteten fehlenden Masse (user-weighted missing mass) erfordert: die Wahrscheinlichkeit, dass ein zufälliger Benutzer einen in der Testphase ungesehenen Defekt ausführt.

Methodik
Die Arbeit schlägt einen distributionsfreien Schätzer vor, der auf der kanonischen Urnenkonstruktion (Hernández-Suárez [10]) basiert und für den Software-Release-Kontext adaptiert wurde.

Dateninterpretation: Jeder Beta-Test-Bericht wird als Stichprobe aus der Benutzerpopulation behandelt, und jeder distinkte Defekt wird als eine „Klasse“ betrachtet. Die Eingangsdaten sind die Mengen der Berichtsanzahlen für jeden Defekt.
Die kanonische Form: Die Autoren definieren ein Populationsmodell, bei dem Klassen unterteilt werden in:
- Gewöhnliche Klassen: Defekte, die mehrfach beobachtet wurden.
- Das Reservoir (All-different-Komponente): Eine theoretische Komponente, die eine unendliche Anzahl von Klassen mit verschwindend geringen Wahrscheinlichkeiten enthält, sodass jede Stichprobe aus diesem Reservoir eine einzigartige, zuvor ungesehene Klasse liefert.
Maximum-Likelihood-Schätzung (MLE):
- Die Arbeit zeigt auf, dass unter der kanonischen Form der Anteil der Defekte, die genau einmal gemeldet wurden ( $s/n$ ) – wobei $s$ die Anzahl der Singletons und $n$ die Gesamtzahl der Berichte ist – der exakte Maximum-Likelihood-Schätzer (MLE) des ungesehenen Anteils ( $U$ ) ist.
- Konservative Verzerrung: Die kanonische Form ordnet jedes Singleton (einen Defekt, der genau einmal gesehen wurde) der „ungesehenen Reservoir“-Komponente zu, anstatt es als seltene gewöhnliche Klasse zu behandeln. Folglich stellt der Schätzer $s/n$ die wahre ungesehene Proportion systematisch über dar. Dies erzeugt eine einseitige, konservative obere Schranke, was die gewünschte Richtung für eine Release-Entscheidung ist (im Sinne der Vorsicht zu handeln).
Umgang mit Architektur: Die Methode ist invariant gegenüber der internen Struktur der Software (Baum vs. DAG). Die Autoren argumenten, dass die „Erreichbarkeit“ eines Defekts bereits in den Berichtszahlen kodiert ist: Ein Defekt hinter einer geschlossenen Tür wird von null Benutzern gemeldet, während ein Defekt auf einem häufig genutzten Pfad von vielen gemeldet wird. Da der Schätzer ausschließlich auf diesen Zählungen basiert, erfasst er automatisch das Risiko eingebetteter, verborgener Defekte, ohne den Erreichbarkeitsgraphen modellieren zu müssen.

Zentrale Beiträge

Neukonzeption des Schätzers (Estimand): Die Arbeit verschiebt den Fokus von der Schätzung einer verbleibenden Defekt-Anzahl hin zur Schätzung der benutzerseitigen Wahrscheinlichkeit, einen ungesehenen Defekt zu begegnen, wodurch die Notwendigkeit eines Operational Profiles entfällt.
Theoretische Rechtfertigung: Sie liefert eine rigorose MLE-Grundlage für den $s/n$ -Schätzer innerhalb des kanonischen Urnen-Frameworks und beweist, dass $s \! / \! n$ der exakte MLE der ungesehenen Masse unter dieser Konstruktion ist.
Konservative obere Schranke: Sie etabliert, dass $s/n$ nicht bloß ein Schätzwert, sondern eine konservative obere Schranke für das Benutzerrisiko ist, da die kanonische Konstruktion Singletons in das ungesehene Reservoir zwingt und somit sicherstellt, dass der Schätzer das Risiko niemals unterschätzt.
Strukturelle Invarianz: Sie demonstriert, dass der Schätzer robust gegenüber der Komplexität der Softwarearchitektur ist, da die Multiplizität der Berichte die Erreichbarkeitsbeschränkungen inhärent erfasst.
Validierung: Der Schätzer wird gegen synthetische Populationen mit bekannter Grundwahrheit (Ground Truth) validiert, wobei die Experimente bestätigen, dass der mittlere Schätzwert die wahre fehlende Masse konsistent erreicht oder übersteigt ( $E[s/n] \geq E[U]$ ).

Ergebnisse

Synthetische Validierung: Experimente mit synthetischen Populationen (sowohl uniform als auch heavy-tailed) zeigen, dass der $s/n$ -Schätzer präzise, aber konsistent konservativ ist. In Szenarien, in denen die Population nahezu gesättigt ist (alle Defekte gefunden), geht die wahre fehlende Masse gegen Null, dennoch bleibt $s/n$ positiv, da die Singletons dem ungesehenen Reservoir überzuordnen sind.
Einseitige Natur: Die Wahrscheinlichkeit, dass der Schätzwert die wahre ungesehene Proportion übersteigt, ist hoch (z. B. 0,89 bis 1,00 in den getesteten Szenarien), was die Zuverlässigkeit der Schranke für risikoaverses Entscheiden bestätigt.
Datenanforderungen: Die Arbeit hebt hervor, dass die Methode Ereignis-Level-Daten (encounter-level data) erfordert (z. B. Telemetrie aus Beta-Kanälen oder Crash-Reports, die erfassen, wie viele Benutzer pro Defekt betroffen waren). Sie stellt explizit klar, dass standardmäßige öffentliche Defekt-Archive ungeeignet sind, da diese typischerweise einen einzigen Eintrag pro Bug aufzeichnen, unabhängig davon, wie viele Benutzer ihn verursacht haben, wodurch die zur Schätzung erforderlichen Multiplizitätsdaten zerstört werden.

Bedeutung und Ansprüche
Die Arbeit beansprucht, eine direkte, distributionsfreie Antwort auf die Frage des Software-Releases zu liefern. Ihre Bedeutung liegt in:

Überbrückung der Lücke: Sie verbindet die statistische Theorie der Abdeckung (Good-Turing) mit den praktischen Einschränkungen des Software-Releases, indem sie insbesondere die „benutzerseitige“ Natur des Risikos adressiert.
Eliminierung von Annahmen: Sie macht die Notwendigkeit von Operational Profiles, Annahmen über die Gesamtzahl der Defekte oder Modellen der internen Programmenstruktur überflüssig.
Entscheidungsunterstützung: Sie bietet eine fundierte, konservative Metrik ( $s/n$ ), die es Entwicklern ermöglicht, zu entscheiden, wann sie releasen: das Testen fortzusetzen, bis die obere Schranke der Wahrscheinlichkeit, auf einen ungesehenen Defekt zu stoßen, unter einen tolerierbaren Risiko-Schwellenwert fällt.

Die Autoren bleiben hinsichtlich der Grenzen der Methode bescheiden und merken an, dass sie auf den Softwarezustand zum Zeitpunkt der Berechnung Anwendung findet und spezifische Arten von Telemetriedaten (Ereignis-Level) erfordert, statt standardmäßiger Bug-Tracking-Logs. Sie behaupten nicht, das Problem der Schätzung der Gesamtzahl der Defekte gelöst zu haben, sondern vielmehr die spezifische Wahrscheinlichkeit der Benutzerexposition gegenüber dem Unbekannten.