Technische Samenvatting: Automatische verbetering van de kwaliteit van Android-app bugrapporten

Probleemstelling

De meeste defecten in mobiele applicaties zijn visueel waarneembaar op het scherm van het apparaat, maar geautomatiseerde mechanismen voor het detecteren en rapporteren ervan zijn vaak niet beschikbaar, met name voor problemen die geen expliciete signalen produceren zoals crashes. Als gevolg hiervan moeten gebruikers, testers en ontwikkelaars handmatig bugrapporten (BRs) indienen. Deze rapporten zijn frequent incompleet, ambigu of onnauwkeurig, en missen vaak cruciale informatie zoals het Geobserveerde Gedrag (OB), het Verwachte Gedrag (EB) en de Stappen om te Reproduceren (S2Rs). Dit probleem is bijzonder acuut bij UI-gecentreerde defecten, waarbij eindgebruikers moeite hebben met het precies beschrijven van de interne werking van de applicatie, de uitvoeringsstatus en de sequentie van GUI-interacties die vereist zijn om een fout te reproduceren.

Bestaande benaderingen om bugrapporten te verbeteren leggen ofwel de last van correctie bij de gebruiker, of genereren inhoud die primair gebaseerd is op de oorspronkelijke rapporttekst. Deze methoden slagen er niet in om te waarborgen dat de gegenereerde informatie de werkelijke werking van de applicatie accuraat weerspiegelt, wat potentieel leidt tot plausibele maar onjuiste reproductiestappen die niet overeenkomen met geldige GUI-interacties. De kernuitdaging is niet enkel het verbeteren van de bugbeschrijving, maar het herstellen van de ontbrekende verbindingen tussen de gerapporteerde buginformatie en de onderliggende UI-uitvoering van de applicatie.

Methodologie: BUGSCRIBE

Het artikel presenteert BUGSCRIBE, een door LLM aangedreven benadering die door gebruikers geschreven Android-bugrapporten automatisch verbetert. Het centrale inzicht is dat hoogwaardige generatie van bugrapporten moet worden geformuleerd als een probleem van het verbinden van bugbeschrijvingen met de UI-uitvoeringsinformatie van de applicatie. BUGSCRIBE maakt gebruik van een component-specifieke grounding-strategie, waarbij het Large Language Model (LLM) de meest relevante context biedt voor het genereren van elk specifiek onderdeel van het bugrapport (OB, EB en S2Rs).

Het systeem werkt via drie fasen:

1. Generatie van het App-uitvoeringsmodel:
   BUGSCRIBE construeert een grafiekgebaseerd uitvoeringsmodel van de applicatie. Knopen vertegenwoordigen unieke GUI-schermen (onderscheiden door UI-componenthiërarchieën), en randen vertegenwoordigen gebruikersinteracties (bijv. taps). Dit model wordt verrijkt met UI-metadata, inclusief componenttypen, ID's, labels en beschrijvingen. Het model wordt opgebouwd met behulp van traces van zowel automatische exploratie (met behulp van een aangepaste CRASHSCOPE) als handmatig gebruik van de app.

2. Contextuele Informatie-extractie:
   Het systeem annoteert het door de gebruiker ingediende rapport om zinnen te identificeren die OB, EB en S2Rs uitdrukken. Vervolgens extraheert het drie belangrijke app-informatie-elementen om als context te dienen voor het LLM:

   • App Schermbeschrijvingen: LLM-gegenereerde samenvattingen van de functionaliteit van het scherm, de lay-out en beschikbare acties.
   • GUI-interacties: Een tupel van (actie, doel-element, bron-scherm, doel-scherm) geëxtraheerd uit het uitvoeringsmodel.
   • Lokalisatie van het Buggy Scherm: Het specifieke scherm waar de fout optreedt, geïdentificeerd door het LLM dat schermen rangschikt op basis van de gerapporteerde bug en schermbeschrijvingen.

3. Generatie van het Bugrapport:
   Met behulp van een zero-shot, taakdecompositie-promptingstrategie genereert BUGSCRIBE de onderdelen van het rapport sequentieel:

   • S2R Generatie: Het LLM brengt de S2R-zinnen van het oorspronkelijke rapport in verband met de interactiesequenties van het uitvoeringsmodel om een geldig reproductiepad naar het buggy scherm af te leiden.
   • OB/EB Generatie: Het LLM genereert het Geobserveerde en Verwachte Gedrag door de beschrijvingen van het oorspronkelijke rapport te koppelen aan de contextuele app-informatie, inclusief het vermoedelijke buggy scherm, de gegenereerde S2Rs en schermbeschrijvingen.
   • Assemblage: Het systeem stelt een gestructureerd rapport samen inclusief een titel, OB, EB, S2Rs en omgevingsdetails.

Belangrijkste Bijdragen

Het artikel levert vier primaire bijdragen:

1. BUGSCRIBE: Een door LLM aangedreven benadering die rapportinformatie koppelt aan app-specifieke uitvoeringsinformatie om accurate, volledige en correcte OB-, EB- en S2R-beschrijvingen te genereren.
2. Data-gestuurde Methodologie: Een methodologie die specifieke app-informatie-elementen identificeert (bijv. GUI-interacties versus schermbeschrijvingen) die het meest effectief zijn voor het genereren van verschillende rapportonderdelen.
3. Empirische Evaluatie: Een uitgebreide evaluatie die aantoont dat BUGSCRIBE de oorspronkelijke bugrapporten verbetert en beter presteert dan LLM-gebaseerde baselines die geen app-specifieke informatie bezitten.
4. Replicatiepakket: Een publiekelijk beschikbare dataset van 58 bugrapporten (10 ontwikkeling, 48 test), ground truth OB/EB/S2Rs, code, prompts en experimentele infrastructuur.

Experimentele Resultaten

De auteurs evalueerden BUGSCRIBE op een testset van 48 bugrapporten van 26 Android-applicaties, waarbij ze het vergeleken met de oorspronkelijke rapporten en drie LLM-gebaseerde baselines (GPT-5.4 en CLAUDE-Opus-4.6 zonder app-context, en U2SBR).

• S2R Kwaliteit: BUGSCRIBE presteerde significant beter dan de baselines en de oorspronkelijke rapporten. Het verbeterde de S2R-kwaliteit met 44,1% tot 82,3% (gemeten aan de hand van de F1-score). Specifiek genereerde het substantieel meer correcte stappen (532–538 vs. 196–345 voor baselines) en verminderde het het aantal extra en ontbrekende stappen aanzienlijk.
• OB/EB Kwaliteit: BUGSCRIBE verbeterde de OB- en EB-kwaliteit met 3,8% tot 35,2%. Het genereerde meer correcte informatie-elementen (158–165 vs. 122 voor de oorspronkelijke rapporten) en verminderde het aantal ontbrekende elementen drastisch (0–3 vs. 59 voor de oorspronkelijke rapporten).
• Effectiviteit van Context: De studie toonde aan dat verschillende componenten profiteren van verschillende context. S2R-generatie leunt zwaar op GUI-interacties en het buggy scherm, terwijl OB/EB-generatie profiteert van gegenereerde S2Rs, beschrijvingen van het buggy scherm en context op schermniveau.
• Kosten: De gemiddelde verwerkingstijd was ongeveer 2,3 minuten per rapport, met kosten variërend van $0,44 tot $0,92 per rapport, afhankelijk van het gebruikte LLM.

Betekenis en Claims

Het artikel claimt dat de primaire betekenis van dit werk ligt in de verschuiving van het paradigma van bugrapportverbetering van tekstgebaseerde herschrijving naar executie-gegronde redenering. Door gebruikersrapporten te verbinden met het werkelijke UI-uitvoeringsmodel van de applicatie, zorgt BUGSCRIBE ervoor dat gegenereerde reproductiestappen en gedragsbeschrijvingen niet alleen taalkundig plausibel zijn, maar ook technisch valide binnen de context van de specifieke applicatie.

De auteurs stellen dat hun component-specifieke grounding-strategie nieuw is, omdat deze de context die aan het LLM wordt verstrekt, afstemt op de specifieke behoeften van het te genereren rapportonderdeel. Deze aanpak adresseert de beperking van eerder werk, dat vaak "plausibele maar onjuiste" beschrijvingen genereert omdat het de grondwaarheid van de uitvoering van de applicatie mist. De resultaten suggereren dat het integreren van dynamische app-analyse met LLM-redenering een levensvatbare weg is naar het automatisch produceren van hoogwaardige, actiegerichte bugrapporten die direct door ontwikkelaars kunnen worden gebruikt voor diagnose en reproductie.