# Testa un sito web con un agente AI e ottieni segnalazioni di bug riproducibili

Fornisci a un agente un piano di test per un sito web, registra il comportamento previsto e quello osservato e trasforma i controlli non superati in segnalazioni di bug che un altro sviluppatore possa riprodurre.

Canonical page: https://beeuni.ai/blog/it/test-website-with-ai-agent

Una pagina può caricarsi correttamente mentre il modulo invia dati errati o la navigazione fa perdere il lavoro svolto. Indica all’agente quali operazioni provare e quale dovrebbe essere il risultato. Il risultato utile è un resoconto del test con prove sufficienti a riprodurre ogni problema.

## Scrivi una descrizione del test per un percorso utente

Fornisci a Beeuni un URL di anteprima raggiungibile e descrivi il percorso. L’agente può aprire il sito nel proprio browser, spostarsi tra le pagine, compilare i campi e controllare il risultato. Per un modulo di contatto, indica le regole di convalida e la conferma attesa. Usa account di test e specifica dove possono essere inviati i moduli. Non includere pagamenti né messaggi destinati a clienti reali.

```
Open the preview URL in your browser and navigate to the contact form.
Use the supplied test account and synthetic form data.
Try required fields, invalid email, successful submission, and repeated clicks.
Record the browser and viewport used.
For each check, report expected behavior, observed behavior, and evidence.
Capture screenshots of failures and save a reproduction report.
Mark checks you cannot complete as blocked. Do not report them as passed.
```

Se la pagina è raggiungibile solo dal tuo portatile, il browser dell’agente avrà bisogno di un’anteprima accessibile o di una connessione configurata esplicitamente per raggiungerla.

## Esamina il resoconto del test prima del riepilogo

Ecco un esempio di resoconto del test di un modulo di contatto. Ogni riga riguarda un controllo distinto: il caricamento corretto della pagina non dice nulla sul funzionamento del modulo.

| Controllo | Risultato atteso | Osservazione a titolo d’esempio | Stato |
| --- | --- | --- | --- |
| Invia il modulo vuoto | I campi obbligatori mostrano degli errori | Gli errori compaiono accanto ai campi obbligatori | Superato |
| Invia un indirizzo email non valido | L’invio viene rifiutato | Compare invece un messaggio di conferma | Non superato |
| Apri il link di conferma | Si apre la pagina di destinazione | L’account di test non può accedere alla pagina di destinazione | Bloccato |

## Una segnalazione di bug riproducibile da un’altra persona

Per ogni problema, chiedi di indicare l’URL, la versione della pagina se nota, lo stato iniziale, i passaggi esatti, i dati di test, il risultato atteso e quello effettivo. Allega uno screenshot, se disponibile. Distingui un errore visibile da una spiegazione della sua causa: il solo messaggio di conferma non dimostra che il server abbia accettato dati non validi.

Ripeti i passaggi che hanno causato il problema partendo da una pagina o sessione nuova. Se il problema si presenta solo a volte, annota quali tentativi non sono riusciti e che cosa è cambiato. Conserva gli errori del browser come prove a supporto, senza considerarli automaticamente la causa.

Ecco un esempio di segnalazione relativa al problema con l’indirizzo email non valido. Sostituisci i dettagli dell’ambiente con l’URL di anteprima e la versione della pagina che hai testato.

```
Title: Contact form shows success for an invalid email
Environment: supplied preview URL; record deployed version
Starting state: fresh page, signed out, empty form
Steps:
1. Enter Test user in the name field.
2. Enter test@ in the email field.
3. Enter Test submission in the message field.
4. Click Send once.
Expected: email error appears; form stays available for correction.
Observed: confirmation replaces the form.
Evidence: screenshot of confirmation; record browser and viewport.
Unknown: whether a contact record or email was created.
```

Lo sviluppatore deve comunque verificare se il server ha rifiutato l’input nonostante il messaggio di esito positivo. Se l’agente è autorizzato ad accedere a una casella di posta o a un registro degli invii di test, chiedigli di controllare. Altrimenti, lascia come ignoto se il server abbia accettato i dati.

## Scegli i controlli di regressione in base alla modifica

Se la correzione riguarda la convalida dell’email, controlla un indirizzo valido, uno vuoto e uno non valido. Includi i formati supportati esplicitamente dal prodotto, come un indirizzo con il segno più. Poi correggi l’input non valido e invia di nuovo. Se non è possibile eliminare l’errore, si tratta di un problema di usabilità distinto.

Se la modifica riguarda lo stato dell’invio, concentrati sui clic ripetuti e sul recupero dopo un errore. Dopo una richiesta non riuscita, il pulsante torna disponibile? Tornando dalla schermata di conferma, i valori precedenti restano nei campi? Scegli i controlli in base al comportamento interessato. Ripetere una lunga lista di controlli dopo ogni piccola modifica può distogliere l’attenzione dal caso che richiede intervento.

Lascia un controllo nello stato «Bloccato» se non è stato possibile eseguirlo. Un errore di accesso potrebbe impedire di avviare il test del modulo, ma non dimostra che il modulo sia difettoso. Se cambia un’etichetta o il layout, potrebbe essere necessario aggiornare le istruzioni di test. Annota gli aggiornamenti accanto alla nuova esecuzione, così chi leggerà il resoconto in seguito potrà distinguere un test aggiornato da una correzione del prodotto.

Registra la nuova versione della pagina e conserva la segnalazione precedente. Si tratta di un controllo funzionale mirato. I test di accessibilità, sicurezza, carico e compatibilità tra browser richiedono ciascuno un ambito e strumenti propri.

Per avviare i controlli dal tuo strumento di sviluppo, consulta la [guida al backend dell’agente](/blog/it/use-beeuni-as-your-agent-backend). Mantieni la stessa descrizione del test e gli stessi campi della segnalazione quando passi dalle richieste manuali a un’integrazione.