Resumo Técnico: Melhorando Automaticamente a Qualidade de Relatórios de Erros de Aplicativos Android

Declaração do Problema

A maioria dos defeitos em aplicativos móveis é visualmente observável na tela do dispositivo, mas mecanismos automatizados para detectá-los e relatá-los são frequentemente indisponíveis, particularmente para problemas que não produzem sinais explícitos como falhas (crashes). Consequentemente, usuários, testadores e desenvolvedores devem enviar relatórios de erros (BRs) manualmente. Esses relatórios são frequentemente incompletos, ambíguos ou imprecisos, muitas vezes carecendo de informações críticas como o Comportamento Observado (OB), o Comportamento Esperado (EB) e os Passos para Reprodução (S2Rs). Este problema é particularmente agudo para defeitos centrados em UI, onde os usuários finais têm dificuldade em descrever com precisão as propriedades internas do aplicativo, estados de execução e a sequência de interações de GUI necessária para reproduzir uma falha.

As abordagens existentes para melhorar os relatórios de erros ou deixam o fardo da correção sobre o usuário ou geram conteúdo primariamente a partir do texto original do relatório. Esses métodos falham em garantir que a informação gerada reflita com precisidade o comportamento real do aplicativo, podendo produzir passos de reprodução plausíveis, mas incorretos, que não correspondem a interações de GUI válidas. O desafio central não é meramente melhorar a descrição do erro, mas sim recuperar as conexões ausentes entre as informações do erro relatado e a execução da UI subjacente do aplicativo.

Metodologia: BUGSCRIBE

O artigo apresenta o BUGSCRIBE, uma abordagem baseada em LLM para melhorar automaticamente relatórios de erros de Android escritos por usuários. O insight central é que a geração de relatórios de erros de alta qualidade deve ser formulada como um problema de conectar descrições de erros com as informações de execução da UI do aplicativo. O BUGSCRIBE utiliza uma estratégia de fundamentação específica por componente, fornecendo ao Modelo de Linguagem de Grande Escala (LLM) o contexto mais relevante para gerar cada componente específico do relatório de erro (OB, EB e S2Rs).

O sistema opera através de três fases principais:

1. Geração do Modelo de Execução do Aplicativo:
   O BUGSCRIBE constrói um modelo de execução baseado em grafos do aplicativo. Os nós representam telas de GUI únicas (distinguidas por hierarquias de componentes de UI) e as arestas representam interações do usuário (ex: toques/taps). Este modelo é enriquecido com metadados de UI, incluindo tipos de componentes, IDs, rótulos e descrições. O modelo é construído usando traços tanto de exploração automatizada (usando um CRASHSCOPE modificado) quanto de uso manual do aplicativo.

2. Extração de Informações Contextuais:
   O sistema anota o relatório enviado pelo usuário para identificar sentenças que expressam OB, EB e S2Rs. Em seguida, extrai três elementos de informação do aplicativo que servem como contexto para o LLM:

   • Descrições de Telas do Aplicativo: Resumos gerados por LLM sobre a funcionalidade da tela, layout e ações disponíveis.
   • Interações de GUI: Uma tupla de (ação, elemento alvo, tela de origem, tela de destino) extraída do modelo de execução.
   • Localização da Tela com Erro: A tela específica onde ocorre a falha, identificada pelo LLM classificando as telas com base no erro relatado e nas descrições das telas.

3. Geração do Relatório de Erro:
   Usando uma estratégia de prompting de decomposição de tarefas zero-shot, o BUGSCRIBE gera os componentes do relatório sequencialmente:

   • Geração de S2R: O LLM mapeia as sentenças de S2R do relatório original para as sequências de interação do modelo de execução para inferir um caminho de reprodução válido que leve à tela com erro.
   • Geração de OB/EB: O LLM gera os Comportamentos Observados e Esperados mapeando as descrições do relatório original para as informações contextuais do aplicativo, incluindo a tela suspeita com erro, os S2Rs gerados e as descrições de tela.
   • Montagem: O sistema monta um relatório estruturado incluindo título, OB, EB, S2Rs e detalhes ambientais.

Principais Contribuições

O artigo apresenta quatro contribuições primárias:

1. BUGSCRIBE: Uma abordagem baseada em LLM que vincula a informação do relatório à informação de execução específica do aplicativo para gerar descrições de OB, EB e S2R precisas, completas e corretas.
2. Metodologia Baseada em Dados: Uma metodologia que identifica elementos de informação específicos do aplicativo (ex: interações de GUI vs. descrições de tela) que são mais eficazes para gerar diferentes componentes do relatório.
3. Avaliação Empírica: Uma avaliação abrangente demonstrando que o BUGSCRIBE melhora os relatórios de erro originais e supera as baselines baseadas em LLM que carecem de informações específicas do aplicativo.
4. Pacote de Replicação: Um conjunto de dados publicamente disponível com 58 relatórios de erros (10 de desenvolvimento, 48 de teste), ground truth de OB/EB/S2Rs, código, prompts e infraestrutura experimental.

Resultados Experimentais

Os autores avaliaram o BUGSCRIBE em um conjunto de teste de 48 relatórios de erros de 26 aplicativos Android, comparando-o com os relatórios originais e três baselines baseadas em LLM (GPT-5.4 e CLAUDE-Opus-4.6 sem contexto de aplicativo, e U2SBR).

• Qualidade de S2R: O BUGSCRIBE superou significativamente as baselines e os relatórios originais. Melhorou a qualidade de S2R em 44,1% a 82,3% (medida pelo F1 score). Especificamente, gerou substancialmente mais passos corretos (532–538 vs. 196–345 para as baselines) e reduziu significativamente os passos extras e ausentes.
• Qualidade de OB/EB: O BUGSCRIBE melhorou a qualidade de OB e EB em 3,8% a 35,2%. Gerou mais elementos de informação corretos (158–165 vs. 122 para os relatórios originais) e reduziu drasticamente os elementos ausentes (0–3 vs. 59 para os relatórios originais).
• Eficácia do Contexto: O estudo descobriu que diferentes componentes se beneficiam de diferentes contextos. A geração de S2R depende fortemente das interações de GUI e da tela com erro, enquanto a geração de OB/EB beneficia-se dos S2Rs gerados, descrições da tela com erro e contexto de nível de tela.
• Custo: O tempo médio de processamento foi de aproximadamente 2,3 minutos por relatório, com custos variando de $0,44 a$0,92 por relatório, dependendo do LLM utilizado.

Significância e Alegações

O artigo alega que a principal significância deste trabalho reside na mudança do paradigma de melhoria de relatórios de erros de reescrita baseada em texto para raciocínio fundamentado na execução. Ao conectar os relatórios dos usuários com o modelo de execução real da interface do usuário do aplicativo, o BUGSCRIBE garante que os passos de reprodução e as descrições de comportamento gerados não sejam apenas linguisticamente plausíveis, mas tecnicamente válidos dentro do contexto do aplicativo específico.

Os autores afirmam que sua estratégia de fundamentação específica por componente é inovadora, pois adapta o contexto fornecido ao LLM com base nas necessidades específicas do componente do relatório que está sendo gerado. Esta abordagem aborda a limitação de trabalhos anteriores, que frequentemente geram descrições "plausíveis, mas incorretas" porque carecem da verdade fundamental (ground truth) do fluxo de execução do aplicativo. Os resultados sugerem que integrar análise dinâmica de aplicativos com raciocínio de LLM é um caminho viável para produzir automaticamente relatórios de erros de alta qualidade e acionáveis, que podem ser usados diretamente por desenvolvedores para diagnóstico e reprodução.