Efficient Black-Box Fault Localization for System-Level Test Code Using Large Language Models

1. Il Problema

La localizzazione dei guasti (Fault Localization - FL) è un passo critico nel debugging, ma le tecniche tradizionali spesso richiedono l'esecuzione ripetuta di test per confrontare esiti di successo e fallimento (es. Spectrum-Based Fault Localization). Questo approccio presenta sfide significative nei contesti industriali moderni:

• Costi di esecuzione elevati: I test a livello di sistema coinvolgono molte interazioni e configurazioni complesse, rendendo l'esecuzione multipla costosa e lenta.
• Fallimenti non deterministici: Alcuni errori sono irriproducibili, rendendo impossibile raccogliere tracce di esecuzione multiple.
• Ambiente "Black-Box": Spesso i team di QA non hanno accesso al codice sorgente del sistema sotto test (SUT), ma solo agli script di test.
• Guasti negli script di test: Un problema trascurato è che molti fallimenti non derivano dal SUT, ma da errori negli script di test stessi (es. asserzioni errate, logiche di configurazione sbagliate). Localizzare questi errori senza eseguire il codice è complesso.

Attualmente, esistono pochi metodi automatizzati per la localizzazione dei guasti negli script di test (TCFL - Test Code Fault Localization), specialmente quelli che operano in modalità statica (senza esecuzione) e che utilizzano modelli linguistici (LLM).

2. Metodologia Proposta

Gli autori propongono un approccio puramente statico e guidato da LLM per la TCFL. Il metodo non richiede l'esecuzione del test, ma si basa su un singolo log di fallimento per stimare la traccia di esecuzione e ridurre lo spazio di ricerca.

L'approccio si articola in due fasi principali:

A. Stima della Traccia di Esecuzione (Execution Trace Estimation)

Poiché la traccia reale non è disponibile (o è troppo costosa da ottenere), l'obiettivo è stimare quali righe di codice sono state effettivamente eseguite prima del fallimento. Vengono proposti tre nuovi algoritmi:

1. Source-to-Log Matching: Identifica le istruzioni di log statiche nel codice (es. print, logging.info con stringhe letterali) e le mappa ai messaggi nel log di esecuzione. Se un messaggio corrisponde univocamente a un'istruzione, questa viene marcata come "eseguita". Se non corrisponde, è "non eseguita".
2. Algoritmo "Fill-in-the-Gaps" (T1): Inferisce lo stato di esecuzione delle righe rimanenti assumendo un flusso sequenziale. Se una riga è nota come eseguita e la successiva è sconosciuta, quest'ultima viene marcata come eseguita (conservativismo).
3. Algoritmo basato su CFG (T2): Utilizza il Grafo del Flusso di Controllo (Control Flow Graph) per gestire i rami condizionali (if/else). Analizza i nodi del grafo per determinare quali percorsi sono stati presi, escludendo i rami non eseguiti.
4. Raffinamento tramite Call Site (CSR): Rimuove le definizioni di funzioni ausiliarie che non hanno siti di chiamata all'interno della traccia stimata, riducendo ulteriormente il codice irrilevante.

Questi algoritmi possono essere combinati (es. intersezione di T1 e T2) per bilanciare accuratezza e pruning (potatura).

B. Prompt Engineering per LLM

Una volta ottenuta la traccia stimata, il codice di test viene "potato" (pruned), rimuovendo tutte le righe stimate come non eseguite. Questo codice ridotto, insieme al messaggio di errore, viene inviato all'LLM tramite un prompt strutturato.

• Input: Messaggio di errore + Codice di test potato.
• Istruzioni: L'LLM deve identificare e classificare le posizioni più sospette (righe, blocchi o funzioni) che causano il fallimento.
• Granularità: Il sistema supporta tre livelli: funzione, blocco (basic block) e riga.

3. Contributi Chiave

1. Definizione del problema TCFL: Identificazione e formalizzazione della localizzazione dei guasti negli script di test a livello di sistema come problema distinto dalla localizzazione nel SUT.
2. Tecnica Statica ed Efficiente: Sviluppo di un metodo che non richiede l'esecuzione del codice, risolvendo i problemi di costi e non-determinismo.
3. Algoritmi di Stima della Traccia: Introduzione di tre algoritmi innovativi per stimare la traccia di esecuzione partendo dai log, permettendo di ridurre lo spazio di ricerca per l'LLM.
4. Valutazione Industriale: Sperimentazione su un dataset reale di 785 casi di test Python difettosi forniti da un partner industriale, utilizzando dati non presenti nel training set degli LLM (evitando data leakage).
5. Open Source: Rilascio del tool e degli algoritmi per la comunità.

4. Risultati Sperimentali

Lo studio è stato condotto su un dataset industriale e confrontato con tecniche state-of-the-art (FauxPy, IRFL, FlexFL).

• Accuratezza della Stima della Traccia: Gli algoritmi combinati (es. CSR(T1,dbt=EXE ∩ T2)) hanno raggiunto un punteggio F1 di circa il 90% nel prevedere quali righe erano state eseguite, preservando oltre l'87% delle posizioni difettose reali.
• Efficienza e Scalabilità:
  • La potatura del codice riduce il numero di token di input fino al 31%.
  • Il tempo di inferenza dell'LLM diminuisce fino al 34% rispetto all'uso del codice completo, senza perdita di accuratezza nella localizzazione.
  • Rispetto al metodo più recente guidato da LLM (FlexFL), la tecnica proposta richiede oltre l'85% in meno di tempo di inferenza e il 93% in meno di token, mantenendo o superando l'accuratezza.
• Livelli di Granularità:
  • La localizzazione a livello di blocco (block-level) offre il miglior compromesso pratico, raggiungendo un Hit@3 (tasso di successo nei primi 3 risultati) dell'81%.
  • Il livello di funzione offre alta precisione, mentre il livello di riga è più difficile a causa dello spazio di ricerca ampio e della mancanza di contesto.
• Confronto con Baseline: La tecnica proposta supera o eguaglia le prestazioni delle tecniche tradizionali e LLM-based adattate per il TCFL, specialmente in termini di efficienza e capacità di gestire contesti complessi.

5. Significato e Impatto

Questo lavoro rappresenta un passo avanti significativo per il debugging automatizzato in ambienti industriali:

• Praticità: Permette di localizzare errori in script di test complessi senza dover eseguire costosi test di sistema, cruciale per pipeline CI/CD veloci.
• Indipendenza dal SUT: Funziona in scenari "black-box" dove il codice sorgente del sistema non è disponibile, una situazione comune nei team di QA.
• Efficienza dei Costi: Riducendo drasticamente l'uso di token e il tempo di inferenza, rende economicamente sostenibile l'uso di LLM per la manutenzione di grandi suite di test.
• Nuova Direzione di Ricerca: Stabilisce una baseline per future ricerche sulla localizzazione dei guasti negli script di test, spostando l'attenzione dalla semplice riparazione alla diagnosi precisa senza esecuzione.

In sintesi, gli autori dimostrano che è possibile localizzare efficacemente i guasti negli script di test complessi utilizzando solo log di fallimento e modelli linguistici, eliminando la necessità di esecuzioni ripetute e riducendo i costi computazionali.