Riepilogo Tecnico: Generazione Continua di Casi di Test per Modelli Linguistici di Grandi Dimensioni con Memoria di Progetto

1. Definizione del Problema

Nei sistemi software su larga scala soggetti a iterazioni agile e consegna continua, mantenere un'efficace copertura dei test è una sfida a causa dell'evoluzione dei requisiti, degli aggiornamenti delle interfacce e dei difetti ricorrenti. Gli approoli convenzionali di scripting per il testing automatico e gli approcci standard basati su Large Language Models (LLM) spesso non riescono a riutilizzare efficacemente i dati storici sui fallimenti o a coprire i rischi emergenti. La letteratura esistente evidenzia limitazioni specifiche:

• Deficit di Contesto: Gli LLM standard faticano con asserzioni instabili e mancano di contesto [1].
• Stagnazione della Copertura: I modelli pre-addestrati possono migliorare i test basati sulla ricerca, ma affrontano comunque plateau di copertura [2].
• Negligenza Storica: Gli approcci che migliorano la copertura spesso non riescono a riutilizzare sufficientemente i difetti storici a livello di progetto [3].
• Squilibrio Strategico: Le strategie di generazione singola faticano a bilanciare la copertura con le capacità di innesco dei difetti [4].
• Lacune di Memoria: Le applicazioni di Test-Driven Development (TDD) con LLM spesso mancano di meccanismi per la memoria dell'evoluzione a lungo termine delle versioni [5].

Il problema centrale è definito come un Compito di Ottimizzazione della Copertura del Rischio Vincolato nell'Evoluzione delle Versioni, dove l'obiettivo è selezionare un set ottimale di casi di test che massimizzi la copertura ponderata dei percorsi di business modificati e degli inneschi di difetti storici, minimizzando al contempo i casi non validi e la duplicazione semantica.

2. Metodologia

La soluzione proposta introduce un framework di Memoria di Progetto (Project Memory), trattando la memoria non come un semplice appendice di Retrieval-Augmented Generation (RAG), ma come uno strato di controllo in evoluzione con il rilascio. La metodologia si compone di tre fasi principali:

2.1 Costruzione della Base di Conoscenza della Memoria di Progetto

Il sistema aggrega asset di test multi-fonte ad granularità di evento, integrando:

• Fonti di Dati: Documenti di requisiti, descrizioni delle interfacce (OpenAPI), commit del codice, report di issue/difetti e script di test esistenti.
• Pulizia dei Dati: Rimozione di testi template e log non validi; conversione di dati sensibili (es. numeri d'ordine, SKU) in token irreversibili o segnaposti generici.
• Segmentazione Semantica: I dati sono taggati per release_id, business_path_id, api_chain, state_pair, risk_tag e trigger_condition.
• Rappresentazione Vettorializzata: Viene costruito un vettore di stato della memoria eterogeneo utilizzando un indice HNSW. Il vettore $\mathbf{m}_i$ per un'unità di memoria è una fusione ponderata di:
  • Embedding semantico ($\mathbf{e}_{sem}$)
  • Embedding di tipo (requisiti, interfaccia, difetto, script)
  • Embedding di versione
  • Embedding di etichetta di rischio
  • Pesi: $\alpha=0.45$ (semantico), $\beta=0.15$ (tipo), $\gamma=0.15$ (versione), $\delta=0.25$ (rischio).

2.2 Meccanismo di Aggiornamento Incrementale della Memoria

La memoria evolve in base ai commit, ai cambiamenti delle interfacce o alle transizioni di difetti. Un Diff Parser estrae le modifiche e, se viene superata una soglia (0.35), la memoria viene versionata; altrimenti, vengono aggiornati i pesi. La formula di aggiornamento dei pesi incorpora:

• Coefficiente di ritenzione storica ($\eta = 0.72$)
• Frequenza di ricorrenza dei difetti
• Livello di rischio del business
• Similiarità semantica con le modifiche correnti
• Decadimento della distanza della versione

2.3 Pipeline Generativa

Il processo di generazione utilizza Llama3.1-70B-Instruct guidato dai seguenti passaggi:

1. Recupero della Memoria Relativa al Rischio: Un vettore di query viene costruito dai cambiamenti richiesti e dai diff delle API. L'indice HNSW recupera i top-50 moduli di memoria, che vengono poi riclassificati da un controllore di feedback del rischio basato sulla ricorrenza dei difetti, l'importanza del percorso e la distanza della versione.
2. Costruzione del Prompt: I top-12 ricordi di rischio, i diff delle interfacce correnti e le asserzioni di fallimento storiche vengono formattati in frammenti JSON. Il prompt include campi per Scenario, API Chain, Precondizioni, Confini di Input, Memoria di Rischio, Asserzioni Attese e Casi Negativi.
3. Generazione e Validazione: Il modello genera candidati con parametri vincolati (Temperatura=0.2, Top-p=0.85).
4. Ded duplicazione e Controllo di Coerenza: I casi generati subiscono:
   • Ded duplicazione Semantica: Utilizzando Sentence-BERT con una soglia di similarità del coseno di 0.86.
   • Verifica di Asserzione e Stato: Controllo di nuovi valori limite o rami di eccezione.
   • Validazione di Schema e Macchina a Stati: Garantire la conformità OpenAPI e le transizioni di stato valide (es. impedire Pagato $\to$ Creato).

3. Contributi Chiave

• Modellazione della Memoria Eterogenea Versionata: Superamento del RAG statico verso un sistema di memoria dinamico che traccia l'evoluzione della versione e del rischio.
• Feedback di Innesco Difetto: Un meccanismo che pesa il recupero della memoria in base alla ricorrenza dei difetti storici e al rischio di business.
• Selezione del Contesto Consapevole del Rischio: Una strategia di re-ranking che prioritizza i percorsi densi di difetti rispetto ai flussi normali.
• Ded duplicazione Semantica con Preservazione dei Confini: Un processo di filtraggio che rimuove i casi ridondanti mantenendo al contempo le variazioni critiche dei confini e i rami di eccezione.
• Verifica della Coerenza dello Stato: Moduli di validazione che assicurano che i casi di test generati aderiscano alle transizioni di stato valide e ai vincoli di schema.

4. Risultati Sperimentali

Il metodo è stato valutato su un Sistema di Ordini E-commerce reale contenente 214 API backend, oltre 9.600 script storici e 3.180 difetti storici in un ciclo di 14 mesi.

Metriche di Performance (vs No-Memory Prompting):

• Tasso di Casi di Test Efficaci: Ha raggiunto l'88.7% (±1.1%), rispetto al 28.1% del prompting senza memoria.
• Riduzione della Duplicazione: Ha ridotto la duplicazione dell'8.9% (±0.7%).
• Copertura Percorsi ad Alto Rischio: Ha raggiunto il 91.3%.
• Scoperta di Difetti: Ha identificato 61 difetti, un miglioramento del 19.6% rispetto alla baseline senza memoria (51 difetti).

Analisi Comparativa:

• Il metodo proposto ha superato le baseline includendo plain RAG, CODAMOSA, CAT-LM, template di regole e testing supplementare umano.
• Studi di Ablazione: Rimuovendo la memoria di progetto, l'efficienza è scesa al 66.1% e la copertura dei percorsi ad alto rischio al 73.4%. Rimuovendo il re-ranking del rischio, la copertura è scesa all'82.1%. Rimuovendo la ded duplicazione, la duplicazione è aumentata al 21.4%.
• Dimensione del Modello: Sebbene il modello 70B abbia mostrato prestazioni superiori nel ragionamento su lunghe catene di chiamata e nella riparazione delle asserzioni, modelli più piccoli (Llama3.1-8B, Qwen2.5-14B) sono rimasti competitivi (80.4% e 83.6% rispettivamente), suggerendo che il framework non dipende interamente da conteggi massicci di parametri.

5. Significato e Rivendicazioni

Il documento sostiene che la Memoria di Progetto migliora significativamente la capacità di un LLM di comprendere le regole di business a lungo termine, le dipendenze tra interfacce e i pattern di fallimento storici. Trattando la memoria come uno strato di controllo in evoluzione con il rilascio piuttosto che come un'appendice statica, l'approccio affronta con successo la "stagnazione" della copertura dei test negli ambienti di consegna continua.

Gli autori osservano che il metodo è particolarmente efficace nel rilevare fallimenti sensibili alla regressione, come rollback tra interfacce, problemi di recupero coupon, violazioni di idempotenza e discrepanze di rinomina dei campi.

Limitazioni Riconosciute:
L'approccio dipende dalla disponibilità di record di bug completi, pattern di interfaccia chiari e un'architettura backend specifica (sistema di ordini e-commerce). Gli autori avvertono che una documentazione scarsa o architetture complesse potrebbero ridurre il richiamo della memoria e la portabilità. Il framework è presentato come una soluzione specifica per la generazione continua di casi di test in sistemi software in evoluzione, con dati e script anonimizzati forniti per la successiva validazione.