# Come funziona il test delle rotte SMS

Un test di rotta invia contenuti reali attraverso una rotta specifica a terminali specifici in un mercato specifico in una data precisa, poi registra che cosa è arrivato e quando. Dimostra quella rotta su quei terminali in quel momento. Non dimostra ogni terminale, ogni rete né la settimana successiva.

- Un test di rotta dimostra una rotta specifica su terminali specifici in un mercato, in un dato momento.

- Un test non dimostra ogni terminale, ogni rete né le prestazioni future.

- Un report utile riporta il contenuto, i terminali, la rotta, gli stati delle ricevute e la data.

- Un errore indica la rotta, il mittente o il terminale in quel momento.

## Che cosa dimostra un test

Un test di rotta risponde a una domanda circoscritta: se inviamo oggi questo contenuto da questo mittente attraverso questa rotta a questi terminali in questo mercato, che cosa arriva e quanto tempo impiega? La risposta è un’evidenza per quella combinazione. Non è un’affermazione di copertura e non è una previsione. Un secondo terminale, un secondo mercato o una modifica della rotta possono dare un risultato diverso.
Proprio questa delimitazione ne costituisce il valore. Un test che indica i terminali, il contenuto e la data può essere ripetuto e confrontato. Un test che riporta solo una percentuale di consegna no. Chieda il record grezzo: la stringa del mittente visualizzata sul terminale, lo stato della ricevuta, il tempo dall’invio alla ricevuta e il percorso di risposta, se il flusso ne prevede uno.
Metta per iscritto la domanda prima del test. Una domanda come “questa rotta consegna un OTP da questo mittente a un terminale diffuso in questo mercato entro dieci secondi?” produce un risultato utilizzabile. “La rotta è buona?” produce un’opinione.

### Che cosa registra il test di rotta

| Verifica | Che cosa registra il test | Che cosa non dimostra |
| --- | --- | --- |
| Consegna | Terminale, mercato, mittente, contenuto e stato della ricevuta | Che ogni terminale del mercato visualizzi il messaggio |
| Tempo | Dall’invio alla ricevuta, mediana e 95° percentile | La latenza di ogni rete o di ogni ora |
| Mittente | La stringa visualizzata sul terminale | Che la stringa resti invariata dopo una modifica della rotta |
| Risposta | Percorso di risposta, tempo di risposta e contenuto | Che ogni rotta in entrata funzioni |
| Contenuto | Modello esatto, codifica e numero di segmenti | Che ogni filtro lo accetti |
| Ripetizione | La data e le condizioni | Che cosa farà la rotta il mese prossimo |

Un terminale per modello è un campione, non un censimento.

## Come si esegue un test

Si concorda prima la domanda. Si tratta di una nuova rotta, di un nuovo mittente, di un nuovo mercato o di una modifica a una rotta esistente? La domanda determina i terminali, il contenuto e il numero di invii. Poi si scelgono terminali rappresentativi del mercato: più di un modello, più di una rete quando la rotta attraversa più reti, e almeno un terminale sulla rete che si prevede trasporti la maggior parte del traffico.
Si congela il contenuto. Si utilizza il modello che verrà inviato, compresi link, variabili e i caratteri che determinano GSM-7 o UCS-2. Si invia lo stesso contenuto a ogni terminale, si registrano l’ora di invio, l’ora della ricevuta e lo stato, e si conservano i dati grezzi. Se il flusso prevede risposte, si invia una risposta da ogni terminale e si registra quanto tempo impiega ad arrivare. Il test va eseguito nella fascia oraria in cui si prevede il traffico, non solo in una fascia a basso traffico.

### La sequenza di test

1. **Concordare la domanda**

Indicare la rotta, il mittente e il mercato. Mettere per iscritto che cosa costituirebbe un esito positivo.

2. **Scegliere i terminali**

Scegliere più di un modello e, se pertinente, più di una rete. Registrare il modello e la rete.

3. **Congelare il contenuto**

Utilizzare il modello esatto che verrà inviato. Registrare la codifica e il numero di segmenti.

4. **Inviare e registrare**

Rilevare l’ora di invio, l’ID del messaggio e la rotta. Non modificare il contenuto tra un invio e l’altro.

5. **Leggere la ricevuta**

Rilevare lo stato, il codice di errore e l’ora di completamento. Lo stato “consegnato” non equivale a una verifica della visualizzazione.

6. **Ripetere su una seconda rotta**

Inviare lo stesso contenuto su una seconda rotta se serve un confronto. Modificare una variabile alla volta.

7. **Scrivere i limiti**

Indicare che cosa il test non ha coperto: terminali, mercati, fasce orarie, contenuti e date.

### Che cosa contiene un report campione

| Parte | Che cosa contiene |
| --- | --- |
| Ambito | La rotta, il mittente, il mercato e la data |
| Metodo | Come sono stati scelti i terminali e come è stato congelato il contenuto |
| Risultati | Stato di consegna, tempo di consegna e stringa del mittente per ciascun terminale |
| Risposte | Il percorso di risposta e il tempo, quando il flusso prevede risposte |
| Errori | Lo stato della ricevuta, il codice di errore e il terminale |
| Evidenze | I record grezzi e il contenuto utilizzato |
| Limiti | Che cosa il test non dimostra e quando ripeterlo |

Un report senza il contenuto, i terminali o la data è un racconto.

## Leggere un errore

Una ricevuta mancante non equivale a una ricevuta di errore. Una ricevuta mancante significa che il record non è mai arrivato; il messaggio potrebbe comunque aver raggiunto il terminale. Una ricevuta di errore riporta uno stato e spesso un codice di rete che ne indica il motivo: abbonato sconosciuto, abbonato assente, memoria piena, servizio inibito. Legga il codice prima di modificare la rotta.
Una ricevuta con stato “consegnato” ma senza visualizzazione richiede una verifica diversa: il terminale, l’app di messaggistica, la cartella dello spam e la stringa del mittente. Una risposta che non arriva mai indica la rotta in entrata o il tipo di mittente, non il percorso in uscita. Un risultato lento indica la rotta, una coda o un bind soggetto a throttling. Si corregge il passaggio indicato dalle evidenze.
Registri l’errore con gli stessi campi di un esito positivo: terminale, mercato, mittente, contenuto, rotta, ora e stato. Un record di errore privo di questi campi non può essere confrontato con l’esecuzione successiva, ed è proprio nell’esecuzione successiva che si dimostra la correzione.

## Che cosa verificare prima di fidarsi di un report

Chieda la data, i terminali, le reti e il contenuto esatto. Chieda quale rotta ha trasportato il traffico e se era diretta o tramite un aggregatore. Chieda gli stati delle ricevute e i codici di errore, non solo una percentuale. Chieda che cosa il test non ha coperto e quando dovrebbe essere ripetuto.
Poi confronti il report con il proprio traffico. Un test su un solo terminale può dare esito positivo mentre la produzione fallisce su un modello diverso, una rete diversa o un modello di messaggio più lungo. Il [report campione di test di rotta](/it/resources/downloads/route-test-sample-report/) mostra la forma del record. La [guida alla scelta del fornitore](/it/resources/learn/how-to-choose-an-a2p-sms-provider/) trasforma il risultato in domande per il fornitore successivo.

Apra lo strumento delle regole per l’elenco aggiornato dei mercati; resta sulla sua pagina.

### Check what you learned

**Un test consegna a un terminale a Città del Messico. Che cosa ha dimostrato?**

Che questa rotta, questo mittente e questo contenuto hanno raggiunto quel terminale in quel mercato in quella data. Non ha dimostrato altri terminali, altre reti né la settimana successiva.

**Una ricevuta è mancante. Il messaggio è perso?**

Non necessariamente. Il record della ricevuta può mancare anche se il messaggio è arrivato. Verifichi il terminale e il record del fornitore prima di inviarlo di nuovo.

**Che cosa ripeterebbe dopo una modifica della rotta?**

La stessa domanda, lo stesso contenuto e gli stessi terminali sulla nuova rotta, con una seconda rotta per il confronto se la decisione dipende da questo.

## FAQ

**Quanti terminali servono per un test?**

Abbastanza da rappresentare i modelli e le reti rilevanti per il lancio. Un terminale è un campione, non un censimento.

**Un test dimostra la recapitabilità?**

Dimostra la consegna sui terminali testati in quel momento. La recapitabilità su un intero mercato richiede la supervisione del traffico in produzione e test ripetuti.

**Quanto dura un test?**

Gli invii richiedono pochi minuti; raccogliere le risposte e scrivere i limiti richiede più tempo. Concordi l’ambito prima che il test inizi.

**Un test può confrontare due fornitori?**

Sì, se entrambi i test utilizzano lo stesso contenuto, gli stessi terminali, lo stesso mercato e la stessa finestra temporale. Modifichi una variabile alla volta.

**E se un test fallisce?**

Legga prima lo stato della ricevuta e il codice di errore. Poi verifichi il mittente, il terminale e la rotta, e modifichi una sola variabile prima dell’invio successivo.

## Sources

- [3GPP TS 23.040: realizzazione tecnica del servizio di messaggi brevi](https://www.3gpp.org/ftp/Specs/archive/23_series/23.040/) — Accessed: 2026-10-19
- [3GPP TS 23.038: alfabeti e informazioni specifiche della lingua](https://www.3gpp.org/ftp/Specs/archive/23_series/23.038/) — Accessed: 2026-10-19
- [Ricevute di consegna SMPP: stati del messaggio e codici di errore](https://smpp.org/smpp-delivery-receipt.html) — Accessed: 2026-10-19

Updated: 2026-10-19