Similar Pattern Annotation via Retrieval Knowledge for LLM-Based Test Code Fault Localization

Resumen Técnico: SPARK para la Localización de Fallos en Código de Prueba

Definición del Problema
Las fallas de software en el desarrollo moderno a menudo son causadas no por defectos en el Sistema Bajo Prueba (SUT), sino por fallos dentro del propio código de prueba. Este problema, conocido como Localización de Fallos en Código de Prueba (TCFL), es crítico en entornos de Integración Continua (CI) donde se ejecutan frecuentemente grandes suites de pruebas. Sin embargo, TCFL presenta desafíos únicos distintos de la localización de fallos tradicional en SUT:

1. Restricciones de caja negra: El código fuente del SUT a menudo no está disponible, lo que impide el análisis de caja blanca.
2. Señales de diagnóstico limitadas: Las fallas típicamente proporcionan solo mensajes de error y registros parciales, careciendo de trazas de ejecución detalladas.
3. Espacios de búsqueda grandes: Los scripts de prueba de nivel de sistema modernos son complejos e interactúan con múltiples componentes, expandiendo las ubicaciones potenciales de fallos.
4. Falta de soluciones existentes: Aunque existen enfoques de Localización de Fallos Basada en Espectro (SBFL) y Aprendizaje Automático para SUTs, a menudo no son aplicables al código de prueba. El único enfoque existente basado en Modelos de Lenguaje Grande (LLM) (Saboor et al. [59]) depende de la indicación (prompting) estándar con contexto limitado, lo que lucha con escenarios complejos y de múltiples fallos.

Además, si bien las tuberías de CI acumulan una vasta historia de fallas de prueba diagnosticadas y resueltas, aprovechar efectivamente este "conocimiento de depuración" para guiar a los Modelos de Lenguaje Grande (LLM) sigue siendo un desafío abierto. Los enfoques ingenuos de Generación Aumentada por Recuperación (RAG) que inyectan casos de prueba recuperados completos en las indicaciones sufren de consumo excesivo de tokens, límites de ventana de contexto y mala escalabilidad.

Metodología: El Marco SPARK
Los autores proponen SPARK (Anotación de Patrones Similares mediante Conocimiento de Recuperación), un marco integral que integra el conocimiento de depuración acumulado en TCFL basado en LLM sin requerir el reentrenamiento del modelo. SPARK opera bajo la suposición de que las fallas de prueba a menudo se repiten en patrones similares y que está disponible un corpus de casos de prueba etiquetados con fallos.

El marco consta de cuatro componentes principales:

1. Módulo de Filtrado: Selecciona un subconjunto del corpus etiquetado con fallos (base de conocimientos) basado en políticas específicas (por ejemplo, todos los casos disponibles, solo los casos anteriores o los casos temporalmente más cercanos) para gestionar la disponibilidad de datos y reducir el ruido.
2. Motor de Búsqueda de Similitud: Calcula la similitud entre un caso de prueba de "consulta" fallido y la base de conocimientos utilizando incrustaciones vectoriales de mensajes de error concatenados y código de prueba. Recupera el/los caso(s) de prueba etiquetado(s) con fallos más similar(es).
3. Módulo de Recuperación de Contexto: Extrae solo las líneas defectuosas específicas de los casos de prueba similares recuperados, en lugar de todo el código de prueba.
4. Módulo de Anotación: Esta es la innovación central. En lugar de adjuntar ejemplos recuperados a la indicación, SPARK anota selectivamente líneas en el caso de prueba de consulta que son textualmente similares (basado en la distancia de Levenshtein normalizada) a las líneas defectuosas recuperadas. Estas anotaciones se agregan como comentarios en línea (por ejemplo, # !!! alta probabilidad de ser defectuosa !!!).

El caso de prueba de consulta anotado, junto con el mensaje de error y las instrucciones estándar de localización de fallos, se alimenta luego a un LLM de uso general (Qwen2.5-72B en los experimentos). Se guía al LLM para que enfoque su razonamiento en las líneas anotadas, reduciendo efectivamente el espacio de búsqueda mientras mantiene la capacidad de analizar el contexto completo.

Contribuciones Clave

1. Formulación del Problema: El artículo caracteriza el escenario práctico de TCFL en entornos de CI e identifica la oportunidad subutilizada de aprovechar el conocimiento de depuración acumulado.
2. Marco SPARK: Introduce el primer enfoque para utilizar sistemáticamente el conocimiento de depuración aumentado por recuperación para guiar el razonamiento de LLM para TCFL, abordando específicamente los problemas de escalabilidad de RAG ingenuo.
3. Integración Basada en Anotaciones: Los autores proponen un mecanismo ligero que resalta selectivamente líneas sospechosas mediante anotaciones. Esto evita la "explosión del tamaño de la indicación" asociada con la inyección de ejemplos completos, preservando la escalabilidad y la eficiencia de inferencia.
4. Evaluación Exhaustiva: El marco se evalúa en tres conjuntos de datos industriales que contienen casos de prueba de Python defectuosos del mundo real de diferentes productos de software.
5. Disponibilidad de Herramienta y Datos: Los autores proporcionan la implementación de la herramienta y las incrustaciones de conjuntos de datos procesados (debido a restricciones de privacidad) para apoyar la reproducibilidad.

Resultados Experimentales
La evaluación compara SPARK con el enfoque de referencia de TCFL basado en LLM (Saboor et al. [59]) en tres conjuntos de datos (DS1, DS2, DS3) a granularidades de línea y unidad (función/bloque).

• Efectividad: SPARK supera consistentemente a la referencia. A nivel de línea, mejora la Precisión Top-1 en 10.1–19.1 puntos porcentuales (pp) y Hit@1 en un margen similar. Las mejoras en la Recuperación oscilan entre 6.8 y 11.9 pp. Notablemente, SPARK muestra ganancias significativas en la identificación de ubicaciones correctas en casos de prueba complejos que contienen múltiples fallos. Por ejemplo, en el conjunto de datos de mejor rendimiento, Hit@3 alcanza el 85.7%, en comparación con el 60.7% de la referencia.
• Escalabilidad y Eficiencia: A pesar de los pasos de recuperación y anotación, SPARK mantiene costos de inferencia comparables a la referencia. Requiere solo 10–60 tokens de entrada adicionales por caso de prueba en promedio. Los tiempos de inferencia permanecen casi idénticos a la referencia, con aumentos negligibles (máximo ~4 segundos por caso de prueba en configuraciones específicas).
• Robustez:
  • Sensibilidad al Umbral: El enfoque es robusto a las variaciones en el umbral de distancia de anotación ($\epsilon$). El rendimiento se mantiene estable en un rango de 0.00 a 0.15, lo que sugiere que no se requiere una similitud estricta para que las anotaciones sean efectivas.
  • Políticas de Filtrado: Si bien el uso de todos los datos disponibles ($p_{all}$) produce los mejores resultados, las políticas que filtran basándose en la proximidad temporal ($p_{closest-by-time}$) logran un rendimiento casi idéntico mientras reducen el tamaño de la base de conocimientos en ~90%. Esto indica que el método es adaptable a diferentes escenarios de disponibilidad de datos.
  • Estudios de Ablación: Eliminar la búsqueda de similitud (Recuperación Aleatoria) o el módulo de anotación (Sin Anotación) degrada significativamente el rendimiento, confirmando que tanto la relevancia de los ejemplos recuperados como el método de integración (anotación) son críticos.

Significado y Afirmaciones
El artículo afirma que SPARK avanza el estado del arte al demostrar que el conocimiento de depuración aumentado por recuperación puede integrarse efectivamente en la localización de fallos basada en LLM sin comprometer la eficiencia. Al alejarse de la inyección de contexto ingenua hacia una estrategia de anotación dirigida, SPARK permite una localización de fallos más precisa en entornos de CI de caja negra y a gran escala. Los autores enfatizan que este enfoque es particularmente valioso para casos de prueba complejos y de múltiples fallos donde la indicación estándar de LLM a menudo falla en distinguir la causa raíz del síntoma de falla. El trabajo establece una vía práctica para aprovechar los datos históricos de depuración para mejorar la fiabilidad del software en entornos industriales.