💻 computer science

LLM-Based Robustness Testing of Microservice Applications: An Empirical Study

Questo studio empirico dimostra che la strategia di prompt influenza significativamente la diversità e la copertura dei test di robustezza generati da LLM per le API di microservizi, rivelando che un approccio few-shot guidato da una tassonomia supera sia gli ensemble di modelli più grandi sia i prompt fissi nell'esporre modalità di guasto distinte.

Autori originali: Hrushitha Goud Tigulla, Marco Vieira

Pubblicato 2026-05-15

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Hrushitha Goud Tigulla, Marco Vieira

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di possedere un ristorante affollato con una cucina (l'applicazione principale) e diverse postazioni specializzate: un'insalatiera, un grill, una stazione per le bevande e una cassa. Ogni postazione è un "microservizio". Si parlano tra loro per completare il tuo ordine.

Ora, immagina di voler assicurarti che il tuo ristorante non vada in crash se un cliente fa qualcosa di strano. Forse provano a ordinare un'insalata con un numero negativo di porzioni, o provano a pagare senza carta di credito, o inviano un messaggio troppo lungo da leggere. Questo si chiama Robustness Testing (Test di Robustezza): tentare intenzionalmente di rompere il sistema con input "cattivi" per vedere dove fallisce.

Il problema è che gli umani sono stanchi. Non possiamo pensare a ogni cosa strana che un cliente potrebbe fare. Quindi, i ricercatori in questo articolo hanno chiesto: Possiamo usare l'IA (in particolare i Modelli Linguistici su Larga Scala o LLM) per creare questi test strani per noi?

Ecco cosa hanno scoperto, spiegato semplicemente:

1. La Preparazione: Gli Chef IA

I ricercatori hanno assunto tre diversi "Chef IA" (modelli IA di dimensioni e specializzazioni diverse) per scrivere questi test. Loro hanno fornito loro il menu del ristorante (le specifiche API) e chiesto di generare test.

Hanno provato 7 modi diversi di chiedere (chiamati "Strategie di Prompt"):

La Lavagna Vuota: Dire semplicemente "Scrivi alcuni test".
Il Manager Rigido: Fornire loro una lista di controllo esatta di cosa testare.
L'Insegnante: Mostrare loro prima degli esempi di test sbagliati.
Il Pensatore: Chiedere loro di pensare passo dopo passo prima di scrivere.
La Guida Esperta: Fornire loro un manuale di regole su come le cose possono rompersi, più esempi di situazioni specifiche e insidiose.

2. La Grande Scoperta: Come Chiedi Conta Più di Chi Chiedi

La scoperta più sorprendente è stata che il modo in cui poni la domanda conta più di quale IA usi.

La Trappola del "Manager Rigido": Quando hanno dato all'IA una lista di controllo rigida (il prompt "Strutturato"), tutte e tre le IA hanno scritto esattamente gli stessi test. Era come dare a tre chef diversi lo stesso identico foglio di ricetta; hanno tutti preparato lo stesso identico piatto. Questo è negativo perché se la ricetta ha un punto cieco, lo perdi.
Il Successo della "Guida Esperta": Quando hanno dato all'IA un manuale più esempi chiari di situazioni insidiose (come la differenza tra "chiave mancante" e "chiave vuota"), le IA hanno iniziato a pensare in modo diverso. Hanno trovato bug unici che gli altri avevano perso.

L'Analogia: Immagina di cercare le chiavi perse in una casa.

Se dici a tre persone diverse: "Cercate in cucina", tutte guarderanno in cucina. Se le chiavi non sono lì, non trovate nulla.
Se dite loro: "Cercate in cucina, ma controllate anche il frigorifero, il tostapane e il letto del gatto", si spargeranno e troveranno più posti.
L'articolo ha scoperto che cambiare come dici all'IA di cercare (il prompt) era più efficace che assumere un'IA "migliore".

3. Il Paradosso dello "Specialista in Codice"

Una delle IA era uno "Specialista in Codice" (addestrato specificamente per scrivere codice). Potresti pensare che questo sarebbe stato il migliore nel trovare bug.

Il Problema: Quando è stato chiesto di semplicemente "criticare e migliorare" il proprio lavoro (una strategia chiamata Self-Refine), questo specialista ha scritto codice perfetto che in realtà non controllava gli errori. Era come uno chef che ha fatto una torta bellissima ma ha dimenticato di assaggiarla per vedere se era bruciata.
La Soluzione: Quando i ricercatori hanno dato a questo specialista la "Guida Esperta" (il manuale con esempi), è improvvisamente diventato il miglior esecutore, trovando più bug di qualsiasi altra combinazione. Il manuale gli ha dato l'"intento avversario"—la mentalità di provare a rompere le cose, che la sua formazione sul codice non gli aveva dato da solo.

4. La Sorpresa dello "Zero-Shot"

C'era una strategia in cui hanno dato all'IA nessuna istruzione, solo il menu.

Il Risultato: Questa IA ha trovato un tipo specifico di bug che gli altri hanno perso: Bug basati sullo stato.
L'Analogia: Le altre IA erano focalizzate su "L'ingrediente è fresco?" (controllando i dati). L'IA "Zero-Shot" stava pensando: "Aspetta, il cliente ha provato a ordinare il dessert prima di ordinare un primo piatto?" (controllando il flusso).
Lezione: Anche un'IA "stupida" o non guidata può trovare errori logici strani che un'IA altamente guidata perde perché l'IA guidata è troppo focalizzata sulle regole.

5. La Confusione tra "Chiave-Assente" e "Valore-Vuoto"

L'articolo evidenzia una specifica confusione che le IA avevano.

La Regola: "Se un valore manca, impostalo a null."
L'Errore dell'IA: Le IA hanno interpretato questo come "Imposta il valore a una stringa vuota" (come nome="").
La Realtà: Nei sistemi informatici, nome="" (vuoto) e nome (mancante completamente) sono due cose totalmente diverse che rompono il sistema in modi diversi.
La Soluzione: Le IA non riuscivano a distinguere la differenza finché i ricercatori non hanno mostrato loro esempi concreti di entrambi. Una volta vista la differenza, potevano testare entrambi gli scenari.

Riepilogo dei Punti Chiave

Non assumere solo un'IA più grande: Un'IA più piccola con un prompt migliore può battere un'IA gigante con un prompt scadente.
Non essere troppo rigido: Se dai all'IA una lista di controllo rigida, faranno tutti esattamente la stessa cosa. Devi dare loro regole ma lasciarli essere creativi.
Mostra, non solo dire: Se vuoi che l'IA capisca una differenza sottile (come "mancante" vs "vuoto"), devi mostrarle un esempio.
Mixa le tue strategie: Per trovare il maggior numero di bug, non dovresti eseguire solo un test. Dovresti eseguire un mix: alcuni test rigidi, alcuni test guidati e persino alcuni test "jolly" senza istruzioni.

In breve, l'articolo dimostra che come parli all'IA è il segreto per trovare bug nel software, non solo la dimensione dell'IA stessa.

Riepilogo Tecnico: Test di Robustezza Basati su LLM per Applicazioni a Microservizi

Enunciato del Problema
Le architetture a microservizi sono suscettibili a minacce alla affidabilità quando input malformati, mancanti o di valore limite si propagano attraverso servizi dipendenti. Sebbene i test di robustezza esercitino sistematicamente tali input per esporre fallimenti lato server, la generazione di casi di test diversificati ed efficaci rimane una sfida significativa. Sebbene i Large Language Models (LLM) possano generare test dalle specifiche API, non è chiaro se diverse architetture di modelli e strategie di prompt producano insiemi diversificati di modalità di fallimento o se convergano sugli stessi bug. La ricerca esistente si concentra sulla correttezza del codice e sui tassi di compilazione, ma manca di prove empiriche sulla diversità delle modalità di fallimento scoperte tra le configurazioni modello-prompt in sistemi a microservizi in esecuzione.

Metodologia
Gli autori hanno condotto uno studio empirico controllato applicando la generazione di test basata su LLM a due sistemi open-source a microservizi architettonicamente distinti:

TeaStore: Un'applicazione monolingue basata su Java con 6 servizi che comunicano tramite HTTP codificato in modulo.
OTel Astronomy Shop: Un'applicazione poliglotta con 27 servizi (Go, C++, Rust, JS, .NET, ecc.) che comunicano tramite API JSON e gRPC.

Lo studio ha utilizzato 3 LLM open-source (14B, 32B specializzati in codice e 70B parametri) e 7 strategie di prompt raggruppate in tre categorie:

Baseline: ZeroShot (solo specifica API) e Structured (tabella di violazione pre-costruita che mappa endpoint a mutazioni).
Tecniche Consolidate: FewShot (esempi di pattern di fallimento), Chain-of-Thought (CoT) e Self-Refine.
Strategie di Conoscenza di Dominio: Guided (incorporando la tassonomia delle mutazioni da Vieira et al. [1] come contesto) e GuidedFewShot (aggiungendo la classificazione dei fallimenti CRASH ed esempi concreti che distinguono le mutazioni chiave-assente da quelle valore-vuoto).

La pipeline sperimentale ha coinvolto la generazione di codice di test Java/JUnit 5, la pulizia degli output, la loro esecuzione contro distribuzioni Docker live e la classificazione dei fallimenti di robustezza basata sui codici di stato HTTP $\ge$ 500 (la classe "Abort"). Lo studio ha definito le Modalità di Fallimento (FMs) come triple uniche (endpoint, parametro, tipo-di-mutazione) verificate contro il codice sorgente, identificando 9 FMs per TeaStore e 14 per OTel. La diversità è stata misurata utilizzando la similarità di Jaccard a coppie degli insiemi di FM attivati.

Principali Contributi

Dominanza della Strategia di Prompt: Prove empiriche che dimostrano che la strategia di prompt spiega più variazione nella diversità dei test rispetto alla dimensione del modello. Cambiare il prompt per un modello fisso produce una maggiore variazione nell'insieme delle modalità di fallimento rispetto a cambiare il modello sotto un prompt fisso.
Collasso Strutturato: Identificazione di un fenomeno in cui un prompt prescrittivo (Structured) causa tutti i modelli a produrre insiemi di modalità di fallimento identici (similarità di Jaccard = 1.00), eliminando efficacemente la diversità.
Nuove Strategie di Prompt: Introduzione delle strategie Guided e GuidedFewShot che incorporano tassonomie di mutazioni come contesto di dominio. GuidedFewShot affronta specificamente l'ambiguità delle regole di mutazione (ad esempio, distinguere tra rimuovere una chiave e impostare un valore su vuoto) attraverso esempi concreti.
Trasformazione delle Prestazioni: Prove che la conoscenza di dominio può trasformare una configurazione a copertura zero nella più performante. Il modello specializzato in codice (qwen2.5-coder:32b) ha attivato zero fallimenti sotto Self-Refine ma ha raggiunto la copertura singola più alta (56% su TeaStore, 57% su OTel) sotto GuidedFewShot.
Modello Singolo vs. Multi-Modello: Dimostrazione che variare le strategie di prompt per un singolo modello supera l'uso di più modelli con un singolo prompt. Ad esempio, qwen2.5-coder:32b ha raggiunto il 100% di copertura FM su OTel variando i prompt tra tre strategie, superando qualsiasi ensemble multi-modello sotto un prompt fisso.

Risultati

Copertura: Nessuna esecuzione singola ha raggiunto la copertura completa su nessuno dei due sistemi (la copertura singola massima è stata del 57%). Tuttavia, la copertura di unione è variata significativamente per strategia. FewShot ha raggiunto l'89% di copertura di unione su TeaStore, mentre GuidedFewShot ha raggiunto il 64% su OTel.
Diversità: Il prompt Structured ha risultato in zero diversità (J=1.00). Self-Refine su OTel ha prodotto la massima diversità (J=0.00) ma con bassa copertura. GuidedFewShot ha mantenuto una bassa similarità (alta diversità) raggiungendo al contempo un'alta copertura, in particolare su OTel (J=0.12).
Il Limite "Chiave-Assente": Lo studio ha rilevato che gli LLM forniti solo di regole tassonomiche (in Guided) hanno fallito sistematicamente nel generare mutazioni "chiave-assente" (omettendo una chiave di parametro), interpretando "sostituisci con null" come impostare un valore su una stringa vuota. GuidedFewShot ha risolto questo problema fornendo esempi espliciti di entrambi i tipi di mutazione.
Fallimenti Basati sullo Stato: ZeroShot è stata l'unica strategia a scoprire modalità di fallimento basate sullo stato (ad esempio, rimuovere un elemento dal carrello senza autenticazione), che le strategie focalizzate sui parametri hanno ignorato.

Significato e Affermazioni
Il paper afferma che per i test di robustezza nei microservizi, l'ingegneria del prompt è più critica della selezione del modello. Gli autori sostengono che i praticanti non dovrebbero affidarsi a una singola configurazione modello-prompt, poiché ciò fornisce una visione incompleta della superficie di fallimento del sistema. Invece, raccomandano:

Utilizzare GuidedFewShot come una solida baseline per scenari di modello singolo e prompt singolo grazie alla sua alta copertura singola e alla diversità mantenuta.
Impiegare il testing multi-configurazione (variando i prompt per un singolo modello) come un percorso più efficiente verso un'alta copertura rispetto all'esecuzione di più modelli con un singolo prompt.
Includere almeno un'esecuzione ZeroShot per catturare fallimenti basati sullo stato che le strategie focalizzate sulle mutazioni trascurano.
Riconoscere che la conoscenza di dominio (tassonomie di mutazioni) deve essere accompagnata da esempi concreti per disambiguare implementazioni a livello di protocollo (ad esempio, gestione dei parametri HTTP) che gli LLM potrebbero interpretare erroneamente in base alle distribuzioni dei dati di addestramento.

Lo studio conclude che, sebbene gli LLM possano generare test di robustezza, la loro efficacia dipende fortemente da come la conoscenza di dominio è inquadrata nel prompt, e che una combinazione di strategie è necessaria per massimizzare la scoperta di fallimenti.