E-Test: E'er-Improving Test Suites

Riepilogo Tecnico: E-Test: Suite di Test in Continua Evoluzione

Definizione del Problema

Le suite di test sono intrinsecamente imperfette e richiedono un arricchimento continuo per mantenere l'affidabilità del software. Sebbene i tester possano teoricamente aggiungere nuovi casi di test per coprire scenari di esecuzione inesplorati, identificare questi scenari — in particolare quelli che emergono dall'uso in produzione — è laborioso e complesso, specialmente per sistemi software ampi e longevi. Gli approcci esistenti, come il testing di regressione (che si concentra sulla selezione o sulla prioritizzazione di test esistenti) e il field testing (che esegue il software in produzione), non affrontano pienamente il divario tra lo spazio di esecuzione coperto da una suite di test e le effettive esecuzioni sperimentate in produzione. Semplicemente aggiungere tutti gli scenari di produzione osservati a una suite di test è impraticabile poiché porterebbe a un'esplosione ingestibile della dimensione della suite stessa. La sfida centrale consiste nello scremare efficientemente enormi set di scenari di produzione per identificare quelli che sono realmente "necessari al test" (non coperti ma corretti) o "propensi all'errore" (non coperti e fallimentari) senza il costo proibitivo di eseguire tutti i casi di test esistenti contro ogni nuovo scenario.

Metodologia: E-Test

Gli autori propongono E-Test, un approccio progettato per creare suite di test "e'er-improving" (in continua evoluzione) che crescono automaticamente integrando nuovi casi di test derivati da dati di produzione. E-Test opera classificando gli scenari di esecuzione in tre categorie rispetto a una suite di test esistente:

1. Già testati: l'input è equivalente a un test esistente (stessa partizione).
2. Necessari al test (Need-test): l'input non è equivalente a nessun test esistente, l'esecuzione ha successo e copre un nuovo comportamento del codice.
3. Propensi all'errore (Error-prone): l'input non è equivalente a nessun test esistente e l'esecuzione fallisce (rivela un bug).

E-Test evita l'impraticabilità di eseguire tutti i test sfruttando i Large Language Models (LLM) per eseguire questa classificazione. Il sistema si compone di tre fasi principali:

1. PreProcessor

Questa fase costruisce un prompt strutturato per l'LLM. Estrae tre componenti chiave da uno scenario di esecuzione:

• MUT (Method Under Test): il codice sorgente del metodo e dei suoi metodi strettamente correlati (limitato a circa 3K token).
• MUT Tests: la suite di test esistente per il metodo (limitata a circa 4K token).
• MUT Input: i parametri di input specifici e il codice di contesto circostante (limitato a circa 1K token).

Il PreProcessor istanzia quindi un template di prompt contenente cinque query specifiche progettate per valutare le caratteristiche dello scenario:

• Q1: L'input è simile ai test esistenti?
• Q2: L'input copre più righe o rami rispetto ai test esistenti?
• Q3: Il metodo si comporterà diversamente con questo input?
• Q4: Il metodo produrrà risultati corretti?
• Q5: L'input rivelerà un bug?

2. Analyzer

L'Analyzer interroga un LLM con il prompt costruito. Per migliorare le prestazioni, E-Test impiega tre tecniche specifiche:

• Fine-tuning: l'LLM (nello specifico GPT-3.5 Turbo negli esperimenti) viene sottoposto a fine-tuning su un dataset di scenari etichettati (già testati, necessari al test, propensi all'errore) per migliorare l'accuratezza della classificazione.
• Retrieval-Augmented Generation (RAG): per superare i limiti della finestra di contesto con codebase di grandi dimensioni, viene utilizzato il RAG per recuperare ed incorporare (embed) snippet di codice rilevanti relativi al prompt, fornendo questo contesto all'LLM.
• Few-shot Learning: esempi fissi di ciascun tipo di scenario sono inclusi nel prompt per guidare il modello.

3. PostProcessor

Il PostProcessor aggrega le risposte dell'LLM alle cinque query. Un meccanismo di "Votazione" (Voter) classifica lo scenario in base al pattern di risposte Sì/No che meglio corrisponde alla tabella di verità attesa per ogni categoria (ad esempio, uno scenario propenso all'errore dovrebbe rispondere No alla somiglianza, Sì alla differenza di copertura, Sì al comportamento differente, No alla correttezza e Sì alla rivelazione del bug). I pareggi vengono risolti dando priorità a propensi all'errore > necessari al test > già testati per garantire la robustezza. Per gli scenari classificati come necessari al test o propensi all'errore, un Generatore di Casi di Test produce automaticamente casi di test JUnit continuando la conversazione con l'LLM.

Contributi Chiave

Il documento apporta i seguenti contributi allo stato dell'arte del testing del software:

• Framework Concettuale: introduce il concetto di "suite di test in continua evoluzione", spostando la prospettiva dalla manutenzione statica all'arricchimento continuo e automatizzato basato sui dati di produzione.
• Approccio E-Test: definisce un approccio innovativo che combina LLM, prompt engineering, fine-tuning e RAG per classificare gli scenari di esecuzione senza eseguire l'intera suite di test.
• Creazione del Dataset: fornisce un dataset di 1.975 scenari di esecuzione raccolti da Defects4J e quattro progetti open-source Java altamente stimati (Spring Boot, Apache ShardingSphere, Apache Dolphinscheduler, Micrometer), categorizzati nelle tre classi target.
• Generazione di Casi di Test: presenta un meccanismo per generare automaticamente casi di test JUnit partendo dagli scenari identificati e valuta la loro capacità di rivelare fallimenti.

Risultati Sperimentali

La valutazione è stata condotta sul dataset di 1.975 scenari, confrontando E-Test con gli approcci all'avanguardia di regression testing (FAST++) e field testing (field-ready testing), nonché con gli LLM standard (vanilla).

• Prestazioni di Classificazione: E-Test ha raggiunto un F1-score medio di 0,55. Questo supera significativamente:
  • Il regression testing all'avanguardia (FAST++): F1-score di 0,34 (miglioramento relativo del 61,8%).
  • Il field-ready testing: F1-score di 0,30 (miglioramento relativo dell'83,3%).
  • Gli LLM vanilla (senza fine-tuning o RAG): F1-score massimo di 0,39.
  • Un classificatore casuale: F1-score di 0,33.
• Impatto del Fine-tuning: Il fine-tuning di GPT-3.5 Turbo è stato fondamentale, migliorando l'F1-score medio totale dell'80% rispetto al classificatore casuale di base.
• Impatto del RAG: Il RAG ha fornito miglioramenti marginali per i casi generali, ma ha mostrato un beneficio significativo (guadagno di F1-score del 12%) specificamente per gli scenari con suite di test molto grandi (>16K token) dove i limiti di contesto vengono superati.
• Generazione di Test: Per i bug di Defects4J, E-Test ha generato con successo casi di test che hanno rivelato fallimenti per l'83,2% dei guasti documentati. Dei test generati, il 99,1% era sintatticamente corretto, l'87% compilava e l'83,2% innescava il fallimento con una copertura di rami uguale o superiore rispetto al ground truth.
• Efficienza: È stato rilevato che interrogare gli LLM è significativamente più veloce (0,81–24,97 secondi) rispetto al calcolo diretto della copertura dei rami eseguendo i test (5,12–168,14 secondi), offrendo un compromesso pratico tra precisione e costo.

Significato e Rivendicazioni

Gli autori affermano che E-Test colma efficacemente il divario tra lo spazio di esecuzione esplorato da una suite di test e le esecuzioni sperimentate in produzione. Automatizzando l'identificazione degli scenari "necessari al test" e "propensi all'errore", E-Test riduce l'impegno manuale richiesto per mantenere le suite di test e migliora l'affidabilità del software.

Il documento sottolinea che, sebbene gli LLM da soli (vanilla) siano insufficienti per questo compito specifico, una pipeline accuratamente progettata che coinvolge fine-tuning, prompt strutturati e recupero del contesto (RAG) può raggiungere livelli di prestazione che superano le tecniche attuali. I risultati suggeriscono che E-Test può essere una componente vitale per prodotti software di lunga durata, consentendo alle suite di test di evolversi continuamente insieme ai dati di produzione senza un'esplosione combinatoria. Gli autori notano che l'approccio è attualmente istanziato per il testing unitario, ma mira ad estendersi al testing di integrazione e di sistema affrontando le sfide relative alla qualità del contesto e alla scalabilità.