Flaky Tests in a Large Industrial Database Management System: An Empirical Study of Fixed Issue Reports for SAP HANA

Sintesi Tecnica: Test Instabili in un Sistema di Gestione di Database Industriale di Grandi Dimensioni

Definizione del Problema
I test instabili (flaky tests), che producono risultati inconsistenti quando eseguiti più volte contro la stessa versione del codice sorgente, minano la valutazione automatizzata del codice, ostacolano la fusione del codice (merging) ed erodono la fiducia degli sviluppatori. Sebbene esistano varie cause radice per l'instabilità (ad esempio, concorrenza, timeout, configurazione), le strategie di mitigazione esistenti sono spesso progettate su misura per cause specifiche. Una comprensione completa delle cause radice prevalenti è necessaria prima di valutare strategie di risoluzione generali. Tuttavia, la ricerca precedente suggerisce che le cause radice variano significativamente tra i linguaggi di programmazione, i domini applicativi e le dimensioni dei progetti. Di conseguenza, i risultati di studi su sistemi più piccoli o di domini diversi potrebbero non generalizzarsi a sistemi industriali molto grandi come SAP HANA, un sistema di gestione di database con milioni di righe di codice e vincoli architettonici unici. Inoltre, etichettare manualmente i report dei test instabili per identificare le cause radice è dispendioso e noioso su larga scala.

Metodologia
Gli autori hanno condotto uno studio empirico su 559 report di problemi etichettati come "risolti/fissati" per test instabili all'interno del repository SAP HANA, campionati in un periodo di 34 mesi (2023–2025). Il dataset comprende due tipi primari di test: unit test nativi in C++ e test di sistema basati su Python che interagiscono con un'istanza del database in esecuzione tramite SQL.

Per analizzare le cause radice su larga scala, gli autori hanno impiegato un approccio LLM-as-annotators (LLM come annotatori):

1. Schema di Categorizzazione: Hanno utilizzato una tassonomia di 15 categorie di instabilità derivata da studi correlati (ad esempio, Concorrenza, Timeout, Fragilità dell'Oracle, Isolamento, Piattaforma).
2. Etichettatura Automatica: Tre diversi modelli linguistici di grandi dimensioni (gemini-2.5-pro, gpt-5, claude-4-sonnet) sono stati istruiti per etichettare ogni report del problema in base alla sua descrizione, causa radice, sintomo e campi di risoluzione.
3. Meccanismo di Coerenza: Per garantire l'affidabilità, ogni modello è stato interrogato cinque volte per report. Una risposta era considerata valida solo se il modello assegnava la stessa categoria in 4 casi su 5. Un voto di maggioranza tra i tre modelli determinava l'etichetta finale.
4. Codebook per l'Ambiguità: È stato introdotto un codebook per risolvere le categorie sovrapponibili (ad esempio, dando priorità a "Piattaforma" rispetto a "Timeout" se l'errore è specifico della configurazione, o a "Concorrenza" rispetto a "Gestione della Memoria" se le race condition ne sono il driver).
5. Validazione: L'approccio è stato validato rispetto a una verità di base (ground truth) annotata manualmente su 232 test (accuratezza del 96% nella classificazione del tipo di test) e un sottoinsieme di 50 report di problemi. L'accordo tra i valutatori è stato misurato utilizzando il Kappa di Fleiss (modello-modello: 0,78) e il Kappa di Cohen (modello-umano: 0,63).

Risultati Chiave

• Cause Radice Prevalenti: La Concorrenza è stata identificata come la causa radice più comune in tutto il dataset, apparendo in 130 di 559 report (23%).
• Differenze tra Tipi di Test:
  • Unit Test Nativi (C++): Hanno mostrato una maggiore suscettibilità alla Concorrenza (39% dei report dei test unit) e ai problemi di Piattaforma (12%), probabilmente a causa del testing di funzionalità a basso livello e di caratteristiche specifiche dell'hardware come NUMA.
  • Test di Sistema (Python): Pur essendo influenzati anche dalla Concorrenza (19%), hanno affrontato tassi significativamente più elevati di problemi di Timeout (18%) e Fragilità dell'Oracle (11%). Quest'ultima era spesso attribuita a clausole ORDER BY mancanti o a confronti di stringhe fragili.
• Instabilità Sistemica: Nei report che collegano più test (127 report), la Concorrenza rimane la causa dominante (35%). Tuttavia, la proporzione di instabilità legata alla Piattaforma è aumentata dal 7% (report a singolo test) al 13% (report a test multipli).
• Tendenze Temporali: L'analisi dei dati trimestrali ha rivelato che i tassi di Concorrenza e Fragilità dell'Oracle sono rimasti relativamente costanti. Al contrario, i problemi di Timeout sono diminuiti notevolmente a seguito di un cambiamento architettonico all'inizio del 2024 che ha armonizzato i valori di timeout globali. I problemi di Async Wait hanno mostrato un picco netto (aumento di 2,2 volte) nel secondo trimestre del 2024.

Contributi

1. Valutazione degli LLM per l'Analisi dell'Instabilità: Lo studio dimostra che gli LLM, se guidati da controlli di coerenza e da un codebook specifico, possono raggiungere un accordo sostanziale con gli annotatori umani (Kappa = 0,63), consentendo un'analisi dell'instabilità su larga scala in contesti industriali.
2. Analisi Comparativa dei Tipi di Test: Il lavoro fornisce un confronto dettagliato tra le cause radice dell'instabilità nei test unit nativi e nei test di sistema all'interno di un singolo progetto industriale su larga scala, evidenziando sfide distinte per ciascun tipo.
3. Panoramica Longitudinale: Lo studio traccia l'evoluzione dei report dei problemi di instabilità nel tempo, identificando come le intervezioni architettoniche (ad esempio, l'armonizzazione dei timeout) impattino specifiche categorie di fallimento.

Significatività e Rivendicazioni
Gli autori affermano che i loro risultati evidenziano la dipendenza dal contesto delle cause radice dell'instabilità. Nello specifico, concludono che la Concorrenza è la sfida primaria in SAP HANA, ma la natura del problema differisce per tipo di test. Il documento sostiene che la ricerca futura sulla mitigazione dell'instabilità non debba assumere una soluzione "taglia unica"; invece, gli approcci devono essere valutati per la loro generalizzabilità attraverso diversi tipi di test (unit vs. system).

Inoltre, gli autori suggeriscono che l'identificazione delle cause radice sia intrinsecamente un compito a multi-etichetta. L'osservazione che diverse categorie spesso si sovrappongono all'interno di un singolo test (ad esempio, un timeout che si verifica solo su una specifica piattaforma a causa di una race condition) implica che gli strumenti futuri dovrebbero mirare a comprendere le interdipendenze tra i fattori contribuenti piuttosto che isolare una singola causa radice. Lo studio posiziona gli LLM come uno strumento vitale per scalare questa analisi complessa in grandi ambienti industriali.