Applicazioni AI
Testare le applicazioni AI: cosa si rompe e come testarlo.
Un'app LLM fallisce in modi in cui una normale app web non fallisce. Il modello restituisce ogni volta qualcosa di diverso, quindi non puoi asserire sulla risposta: asserisci su tutto ciò che la circonda: che una risposta arrivi, venga trasmessa in streaming, si fermi, fallisca in modo visibile, rispetti un limite e non restituisca mai dati che la persona non può vedere.
Ultimo aggiornamento: 24 agosto 2026
In cosa il test di un'applicazione AI è diverso?
L'interfaccia è la stessa. Il contratto no. L'automazione dei test tradizionale poggia su un'asserzione che vale due volte: clicca qui, vedi lì. Un modello rompe questo presupposto alla prima esecuzione, ed è per questo che spesso i team concludono che le loro funzioni AI non possano proprio essere testate in regressione, e poi le rilasciano senza test.
Si può. Il trucco è spostare l'asserzione dalla prosa alle parti che sono deterministiche: la risposta è arrivata entro un budget, è stata interpretata secondo lo schema richiesto, ha citato un documento che questo utente può leggere, un rifiuto è stato mostrato come rifiuto, un nuovo tentativo non ha addebitato due volte. Tutto questo è normale automazione. Giudicare se la risposta sia buona è un problema di valutazione, richiede la tua verità di riferimento e appartiene a un harness accanto ai tuoi prompt piuttosto che a una suite di regressione.
Cosa si rompe davvero in un'app LLM
Sono comportamenti, non opinioni sulla qualità dell'output, ed è questo che li rende testabili. Ognuno raggiunge gli utenti come un bug del prodotto e non come una cattiva risposta.
| Errore | Come raggiunge l'utente | Il test |
|---|---|---|
| La risposta viene trasmessa in streaming, poi si ferma a metà | Una connessione caduta a metà streaming lascia a schermo una risposta scritta a metà, senza errore e senza nuovo tentativo. Gli utenti la leggono come la risposta. | Interrompi la risposta a metà streaming e verifica che la UI mostri uno stato di errore, non una risposta troncata. |
| Il modello è lento e la UI non ha una risposta per questo | Un p95 fermo a quaranta secondi mentre l'interfaccia non offre avanzamento, annullamento né timeout. Le persone cliccano di nuovo, e ora due richieste vengono fatturate. | Tieni aperta la risposta oltre il timeout e verifica che ci sia uno stato visibile, un modo per annullare e nessuna richiesta duplicata al secondo clic. |
| Il provider restituisce 429 o 503 | I limiti di frequenza e i disservizi dei provider sono ordinaria amministrazione, non eccezioni. Le app che li trattano come impossibili mostrano un errore grezzo o uno spinner infinito. | Restituisci 429 e 503 dal provider e verifica che l'app degradi a un messaggio su cui l'utente può agire. |
| Risposte vuote, rifiutate e filtrate per sicurezza | Il modello rifiuta, o scatta il filtro di sicurezza, e l'interfaccia mostra un fumetto vuoto perché gestisce solo il percorso felice. | Forza un rifiuto e un completamento vuoto; verifica che nessuno dei due produca un messaggio vuoto o un layout rotto. |
| La conversazione perde il contesto | La cronologia viene tagliata per stare nella finestra e l'assistente dimentica in silenzio ciò che gli è stato detto tre messaggi fa. Sembra che il prodotto sia stupido. | Porta una conversazione oltre il limite di contesto e verifica che l'app dica cosa ha scartato invece di scartarlo in silenzio. |
| Le chiamate agli strumenti partono più di una volta | Un agente ripete un passaggio il cui strumento è già stato eseguito. Qualunque cosa quello strumento abbia fatto — un'email, un addebito, una scrittura — accade due volte. | Fai andare in timeout una chiamata a uno strumento dopo che è riuscita e verifica che il nuovo tentativo non ripeta l'effetto collaterale. |
| Il recupero restituisce il documento di un altro tenant | Il vector store è filtrato nel prompt invece che nella query, quindi un recupero che ignora l'istruzione restituisce dati che l'utente non può leggere. | Interroga come un tenant un documento di proprietà di un altro e verifica che sia assente dall'insieme recuperato, non soltanto non citato nella risposta. |
| Il costo sfugge di mano senza un tetto | Nessun limite per utente, quindi un ciclo o un account automatizzato diventa un conto di cui nessuno si accorge fino alla fattura. | Chiama ripetutamente lo stesso endpoint e verifica che esista un limite — per utente, per chiave, per minuto. |
Sicurezza
Test di sicurezza degli LLM: la superficie che vale la pena controllare
Una funzione AI di solito arriva collegata a due cose che una funzione normale non ha: un endpoint a pagamento e un componente che segue le istruzioni trovate in qualsiasi cosa legga. Entrambe ampliano la superficie di attacco in modi per cui una revisione standard della sicurezza applicativa non era stata scritta.
Ordinati qui sotto in base a quanto spesso vengono trovati davvero — che non è l'ordine in cui se ne scrive.
- 01
Chiavi del provider nel bundle del client
Una chiave di un provider di modelli inclusa nel JavaScript front-end, o raggiungibile tramite una route proxy senza autenticazione davanti.
Chiunque abbia gli strumenti per sviluppatori può spendere la tua quota. È la cosa più economica da controllare in questo elenco e la più costosa da perdere.
- 02
Prompt injection tramite contenuti
Istruzioni nascoste in qualcosa che il modello legge — un documento caricato, una pagina estratta, un ticket di assistenza, il corpo di un'email — che il modello poi segue.
L'aggressore non tocca mai il tuo campo di input. Tutto ciò che il tuo sistema acquisisce è un input, che tu l'abbia progettato come tale o no.
- 03
Injection che raggiunge uno strumento
Istruzioni iniettate che spingono un agente a chiamare uno strumento: inviare un messaggio, scrivere un record, fare una richiesta a un indirizzo interno.
Qui l'injection smette di essere un imbarazzo e diventa un incidente. Il raggio d'azione è tutto ciò che l'agente può fare.
- 04
Divulgazione del prompt di sistema e dei segreti
Far ripetere al modello le proprie istruzioni, le definizioni dei suoi strumenti o frammenti di configurazione che gli sono stati dati.
Il prompt di sistema spesso contiene regole di business, endpoint interni e a volte credenziali che nessuno intendeva metterci.
- 05
Recupero tra tenant
Un recupero limitato chiedendo gentilmente al modello invece di filtrare la query.
Un prompt non è un controllo degli accessi. Se il filtro vive nelle istruzioni, un'istruzione ignorata è una violazione dei dati.
- 06
Output reso come markup o codice
Output del modello inserito nella pagina come HTML, o in una shell, una query o una eval.
Injection classica con una nuova fonte. Il modello è ora un input non attendibile, e un aggressore può influenzarlo.
- 07
Spesa illimitata come denial of service
Un endpoint che chiama un modello a pagamento senza limite di frequenza, senza tetto per account e senza limite di dimensione su ciò che accetta.
L'attacco non è abbatterti. È far salire un conto finché non ti abbatti da solo.
- 08
Cosa conservano i log
Prompt e completamenti scritti nei log e negli analytics — compreso tutto ciò che un utente vi ha incollato.
Le persone incollano credenziali di produzione e dati dei clienti nelle caselle di chat. La conservazione dei tuoi log è ora una questione di protezione dei dati.
Cosa automatizza QA Spider, e cosa no
Dichiarato in modo abbastanza preciso da poterci chiamare a risponderne.
Questo lo automatizziamo
- Guida il tuo prodotto in un browser reale, quindi i casi di streaming, timeout, nuovo tentativo, stato vuoto e stato di errore qui sopra sono normali test UI: girano con una pianificazione e a ogni rilascio.
- Controlla l'API sotto l'interfaccia, comprese le route che il tuo front-end chiama per raggiungere un modello.
- Apre ciò che fallisce come ticket in Jira, Azure DevOps, ClickUp, GitHub o Linear, con i passaggi che lo riproducono e uno screenshot.
- Esegue una verifica di sicurezza superficiale sul sito pubblico: trasporto e header di sicurezza, flag dei cookie, contenuti misti, esposizione dei moduli, DNS e protezione dallo spoofing email.
Questo non lo facciamo
- Al momento non forniamo una suite automatizzata di prompt injection o jailbreak. Se qualcuno ti dice che il suo crawler lo fa di serie, chiedigli di mostrarti le asserzioni.
- Non valutiamo se una risposta sia corretta. È un problema di eval, richiede la tua verità di riferimento ed è una disciplina diversa dai test di regressione.
Domande che ci fanno sul testare le app AI
- In cosa il test di un'applicazione AI è diverso dal test di una normale app web?
- L'interfaccia è la stessa; l'output no. Una normale app restituisce due volte la stessa risposta, quindi puoi asserire su di essa. Un modello restituisce ogni volta qualcosa di diverso, quindi le asserzioni si spostano sulla forma e sul comportamento attorno alla risposta: che arrivi, venga trasmessa in streaming, si fermi, fallisca in modo visibile e costi ciò che deve.
- Come si scrive un'asserzione quando l'output cambia ogni volta?
- Asserisci sul contratto, non sulla prosa. Che una risposta sia arrivata entro il budget, che sia stata interpretata secondo lo schema richiesto, che abbia citato un documento che l'utente può vedere, che un rifiuto venga mostrato come rifiuto. Giudicare le parole è un'eval, da eseguire separatamente dalla suite di regressione.
- Che cos'è la prompt injection e come si testa?
- Istruzioni nascoste nei contenuti che il tuo sistema legge — un documento, una pagina web, un ticket — che il modello poi esegue. La si testa inserendo istruzioni in ogni canale che raggiunge il modello e verificando che l'effetto non si produca mai: nessuno strumento chiamato, nessun dato restituito, nessun prompt di sistema ripetuto.
- Qual è il problema di sicurezza più comune nei prodotti AI?
- Quelli poco appariscenti. Una chiave del provider raggiungibile dal browser, un endpoint del modello senza limite di frequenza e un recupero limitato da un'istruzione nel prompt invece che da un filtro sulla query. Tutti e tre sono più economici da trovare di un jailbreak ingegnoso e più probabili.
- QA Spider può testare il mio prodotto AI?
- Il comportamento attorno al modello, sì: streaming, timeout, nuovi tentativi, rifiuti, stati di errore, limiti di frequenza e l'API sotto l'interfaccia, testati in un browser reale a ogni rilascio. Le suite automatizzate di prompt injection oggi non le forniamo, e preferiamo dirlo piuttosto che lasciartelo scoprire dopo.
- Controllate se il modello dà risposte corrette?
- No. La correttezza richiede la tua verità di riferimento e appartiene a un harness di valutazione che possiedi e versioni insieme ai tuoi prompt. I test di regressione rispondono a un'altra domanda: ciò che funzionava ieri funziona ancora dopo il rilascio di oggi.
Puntalo sul tuo prodotto AI.
Il comportamento attorno al modello — streaming, timeout, nuovi tentativi, rifiuti, limiti di frequenza e l'API sotto l'interfaccia — testato in un browser reale, a ogni rilascio.