# Cómo se prueba una ruta de SMS

Una prueba de ruta envía contenido real por una ruta concreta a teléfonos concretos de un mercado concreto en una fecha, y registra qué llegó y cuándo. Prueba esa ruta en esos teléfonos en ese momento. No prueba todos los teléfonos, todas las redes ni la semana que viene.

- Una prueba de ruta prueba una ruta concreta en teléfonos concretos de un mercado en un momento.

- Una prueba no prueba todos los teléfonos, todas las redes ni el rendimiento futuro.

- Un informe útil lleva el contenido, los teléfonos, la ruta, los estados del acuse y la fecha.

- Un fallo apunta a la ruta, al remitente o al teléfono en ese momento.

## Qué prueba una prueba

Una prueba de ruta responde a una pregunta estrecha: si enviamos este contenido desde este remitente por esta ruta a estos teléfonos en este mercado hoy, ¿qué llega y cuánto tarda? La respuesta es evidencia para esa combinación. No es una afirmación de cobertura ni un pronóstico. Otro teléfono, otro mercado o un cambio de ruta pueden dar un resultado distinto.
Esa estrechez es el valor. Una prueba que nombra sus teléfonos, su contenido y su fecha se puede repetir y comparar. Una que solo informa un porcentaje de entrega, no. Pida el registro crudo: la cadena de remitente que muestra el teléfono, el estado del acuse, el tiempo desde el envío hasta el acuse y la ruta de respuesta si el flujo la necesita.
Escriba la pregunta antes de la prueba. Una pregunta como si esta ruta entrega un OTP desde este remitente a un teléfono común de este mercado en menos de diez segundos produce un resultado útil. La pregunta de si la ruta es buena produce una opinión.

### Qué registra la prueba de ruta

| Comprobación | Qué registra la prueba | Qué no prueba |
| --- | --- | --- |
| Entrega | Teléfono, mercado, remitente, contenido y estado del acuse | Que todos los teléfonos del mercado muestren el mensaje |
| Tiempo | Envío a acuse, mediana y percentil 95 | La latencia de todas las redes o de todas las horas |
| Remitente | La cadena que muestra el teléfono | Que la cadena sobreviva a un cambio de ruta |
| Respuesta | Ruta de respuesta, tiempo de respuesta y contenido | Que todas las rutas entrantes funcionen |
| Contenido | Plantilla exacta, codificación y número de segmentos | Que todos los filtros lo acepten |
| Repetición | La fecha y las condiciones | Qué hará la ruta el mes que viene |

Un teléfono por modelo es una muestra, no un censo.

## Cómo se ejecuta

Primero acuerde la pregunta. ¿Es una ruta nueva, un remitente nuevo, un mercado nuevo o un cambio en una ruta existente? La pregunta decide los teléfonos, el contenido y el número de envíos. Después elija teléfonos que representen el mercado: más de un modelo, más de una red cuando la ruta cruza redes, y al menos un teléfono en la red que espera que lleve la mayor parte del tráfico.
Congele el contenido. Use la plantilla que va a enviar, con enlaces, variables y los caracteres que deciden GSM-7 o UCS-2. Envíe el mismo contenido a todos los teléfonos, registre la hora de envío, la hora del acuse y el estado, y guarde los datos crudos. Si el flujo necesita respuestas, envíe una respuesta desde cada teléfono y registre cuánto tarda en llegar. Ejecute la prueba en la hora en que espera tráfico, no solo en una ventana tranquila.

### La secuencia de la prueba

1. **Acuerde la pregunta**

Nombre la ruta, el remitente y el mercado. Escriba qué significaría aprobar.

2. **Elija los teléfonos**

Elija más de un modelo y, cuando importe, más de una red. Registre el modelo y la red.

3. **Congele el contenido**

Use la plantilla exacta que enviará. Registre la codificación y el número de segmentos.

4. **Envíe y registre**

Capture la hora de envío, el message ID y la ruta. No cambie el contenido entre envíos.

5. **Lea el acuse**

Capture el estado, el código de error y la hora de finalización. Entregado no es una comprobación de pantalla.

6. **Repita en una segunda ruta**

Ejecute el mismo contenido en una segunda ruta si necesita comparar. Cambie una variable cada vez.

7. **Escriba los límites**

Diga qué no cubrió la prueba: teléfonos, mercados, horas, contenido y fechas.

### Qué contiene un informe de muestra

| Parte | Qué contiene |
| --- | --- |
| Alcance | La ruta, el remitente, el mercado y la fecha |
| Método | Cómo se eligieron los teléfonos y cómo se congeló el contenido |
| Resultados | Estado de entrega, tiempo de entrega y cadena de remitente por teléfono |
| Respuestas | La ruta de respuesta y el tiempo, cuando el flujo necesita respuestas |
| Fallos | El estado del acuse, el código de error y el teléfono |
| Evidencia | Los registros crudos y el contenido usado |
| Límites | Qué no prueba la prueba y cuándo repetirla |

Un informe sin el contenido, los teléfonos o la fecha es un relato.

## Leer un fallo

Un acuse ausente no es lo mismo que un acuse fallido. Ausente significa que el registro nunca llegó; el mensaje pudo haber llegado al teléfono. Un acuse fallido trae un estado y a menudo un código de red que nombra el motivo: abonado desconocido, abonado ausente, memoria llena, servicio bloqueado. Lea el código antes de cambiar la ruta.
Un acuse de entregado sin visualización necesita otra comprobación: el teléfono, la aplicación de mensajes, la carpeta de spam y la cadena del remitente. Una respuesta que nunca llega apunta a la ruta entrante o al tipo de remitente, no al camino de salida. Un resultado lento apunta a la ruta, a una cola o a un bind limitado. Corrija el paso que nombra la evidencia.
Registre el fallo con los mismos campos que un aprobado: teléfono, mercado, remitente, contenido, ruta, hora y estado. Un registro de fallo sin esos campos no se puede comparar con la siguiente ejecución, y la siguiente ejecución es donde se demuestra la corrección.

## Qué comprobar antes de confiar en un informe

Pida la fecha, los teléfonos, las redes y el contenido exacto. Pregunte qué ruta llevó el tráfico y si era directa o de agregador. Pida los estados del acuse y los códigos de error, no solo un porcentaje. Pregunte qué no cubrió la prueba y cuándo debería repetirse.
Después compare el informe con su propio tráfico. Una prueba en un teléfono puede aprobar mientras producción falla en otro modelo, otra red o una plantilla más larga. El [informe de muestra de una prueba de ruta](/es/resources/downloads/route-test-sample-report/) muestra la forma del registro. La [guía de proveedores](/es/resources/learn/how-to-choose-an-a2p-sms-provider/) convierte el resultado en preguntas para el siguiente proveedor.

Abra la herramienta de reglas para la lista vigente por mercado; se queda en su propia página.

### Check what you learned

**Una prueba entrega en un teléfono de Ciudad de México. ¿Qué ha probado?**

Que esta ruta, remitente y contenido llegaron a ese teléfono en ese mercado en esa fecha. No ha probado otros teléfonos, otras redes ni la semana que viene.

**Falta un acuse. ¿El mensaje se perdió?**

No necesariamente. El registro del acuse puede faltar aunque el mensaje haya llegado. Compruebe el teléfono y el registro del proveedor antes de reenviar.

**¿Qué repetiría tras un cambio de ruta?**

La misma pregunta, contenido y teléfonos en la ruta nueva, con una segunda ruta para comparar si la decisión depende de ello.

## FAQ

**¿Cuántos teléfonos necesita una prueba?**

Los suficientes para representar los modelos y redes que importan al lanzamiento. Un teléfono es una muestra, no un censo.

**¿Una prueba demuestra la entregabilidad?**

Demuestra la entrega en los teléfonos probados en ese momento. La entregabilidad en un mercado necesita seguimiento de producción y pruebas repetidas.

**¿Cuánto tarda una prueba?**

Los envíos tardan minutos; recoger respuestas y escribir los límites lleva más. Acuerde el alcance antes de empezar.

**¿Se pueden comparar dos proveedores?**

Sí, si ambas pruebas usan el mismo contenido, teléfonos, mercado y ventana de tiempo. Cambie una variable cada vez.

**¿Y si la prueba falla?**

Lea primero el estado del acuse y el código de error. Después revise el remitente, el teléfono y la ruta, y cambie una variable antes del siguiente envío.

## Sources

- [3GPP TS 23.040: realización técnica del servicio de mensajes cortos](https://www.3gpp.org/ftp/Specs/archive/23_series/23.040/) — Accessed: 2026-10-19
- [3GPP TS 23.038: alfabetos e información específica de idioma](https://www.3gpp.org/ftp/Specs/archive/23_series/23.038/) — Accessed: 2026-10-19
- [smpp.org: acuses de entrega, estados y códigos de error](https://smpp.org/smpp-delivery-receipt.html) — Accessed: 2026-10-19

Updated: 2026-10-19