Voltar ao blog Qualidade e confiança

Como criar uma matriz de testes A2P SMS por destino, operadora, remetente e tipo de mensagem

Um guia operacional para criar testes A2P SMS repetíveis, registar evidências técnicas e comparar rotas sem confundir DLR com receção observada no terminal.

Matriz operacional de testes A2P SMS com destinos, redes, remetentes e resultados de entrega

Porque um teste isolado não valida uma rota SMS

Um SMS enviado para um único número, numa única rede e numa única faixa horária descreve apenas esse caso específico. Não demonstra que a mesma rota manterá um comportamento comparável em outros países, redes de subscrição, tipos de remetente, codificações, comprimentos ou conteúdos legítimos.

Uma matriz de testes A2P SMS transforma uma verificação pontual num programa de avaliação repetível. O seu objetivo não é prometer entrega nem substituir a monitorização de produção: é gerar evidências comparáveis para decidir quais as rotas que merecem maior observação, quais os cenários que exigem investigação e em que condições uma rota pode ser avaliada antes de receber mais tráfego.

A principal disciplina consiste em não extrapolar além da amostra. Um resultado favorável num destino não valida um país inteiro; um resultado favorável numa rede não valida necessariamente outra rede; e um DLR favorável não prova, por si só, que uma pessoa viu a mensagem na interface do telemóvel.

  • Trate cada combinação de variáveis como uma célula de teste independente.
  • Mantenha uma versão identificável da matriz e de cada caso executado.
  • Compare apenas células equivalentes ou documente com precisão qual variável foi alterada.
  • Separe os factos observados das declarações contratuais, técnicas ou comerciais de terceiros.
Porque um teste isolado não valida uma rota SMS

O que a matriz deve responder antes de encaminhar tráfego para produção

Antes de aumentar o tráfego, a matriz deve responder a questões operacionais concretas. Que combinações de destino, rede, remetente e conteúdo foram testadas? Que resultados foram observados? Quantas observações comparáveis existem? Que estados foram recebidos, em que sequência e com que atraso? Existiram diferenças entre a aceitação inicial, os callbacks ou DLR e a receção observada num terminal de teste?

Nem todas as decisões exigem o mesmo nível de evidência. Uma rota em exploração pode exigir testes controlados e revisão manual. Uma rota que venha a receber tráfego sensível, como OTP ou notificações transacionais, exige uma cobertura de casos mais próxima da sua utilização real, com limites internos de risco definidos pela equipa responsável.

A matriz também deve tornar visíveis as áreas não testadas. A ausência de um resultado não deve transformar-se numa inferência positiva. Marque as células sem amostra como não avaliadas, e não como corretas.

  • Cobertura: que destinos, redes e cenários estão realmente representados.
  • Repetibilidade: se o mesmo caso pode ser executado e comparado novamente.
  • Evidência: o que ocorreu na plataforma, o que o fornecedor comunicou e o que foi observado de forma independente.
  • Incerteza: o que não pode ser concluído devido ao tamanho da amostra, à falta de terminal de teste ou à variação das condições.
  • Decisão: expandir, manter sob observação, pausar ou investigar.
O que a matriz deve responder antes de encaminhar tráfego para produção

Dimensões básicas de uma matriz de testes A2P SMS

O desenho começa por definir as dimensões que podem alterar o resultado. Normalize o número de destino no formato internacional e mantenha o país como um campo explícito. A Recomendação ITU-T E.164 é a referência adequada para representar a dimensão internacional da numeração.

Não deduza a operadora atual apenas a partir do intervalo numérico. A portabilidade móvel permite manter o MSISDN ao mudar de rede de subscrição. Por isso, convém distinguir a operadora inferida pelo intervalo, quando existir, da operadora ou rede de subscrição observada ou confirmada através de um procedimento autorizado.

Registe o remetente exatamente como foi submetido. O tipo de remetente pode ser alfanumérico, numérico ou outro formato permitido pelo contexto técnico e regulamentar aplicável. Não assuma que o comportamento de um remetente será idêntico ao de outro, mesmo no mesmo destino.

  • País e destino em formato internacional.
  • Rede móvel ou rede de subscrição, com a fonte da atribuição.
  • Tipo de numeração e condição conhecida de portabilidade, quando aplicável.
  • Rota, ligação ou configuração em avaliação.
  • Remetente submetido e respetivo formato.
  • Tipo de mensagem: OTP, transacional ou marketing autorizado.
  • Codificação, alfabeto, comprimento e segmentação.
  • Janela horária e data de execução.

Separe OTP, transacionais e marketing autorizado

OTP, mensagens transacionais e marketing autorizado não devem ser incluídos na mesma conclusão operacional. Embora todos utilizem SMS, normalmente correspondem a expectativas diferentes quanto a conteúdo, oportunidade e rastreabilidade. Um teste deve representar o caso de utilização legítimo que se pretende avaliar, sem reutilizar indiscriminadamente o mesmo texto em todos os cenários.

Para OTP, utilize textos de teste inequívocos, sem dados pessoais e sem códigos que concedam acesso real. Registe o momento de envio e a observação no terminal quando dispuser de um dispositivo de teste controlado. Para mensagens transacionais, utilize uma notificação fictícia e claramente identificada como teste. Para marketing, limite os ensaios a números autorizados e a conteúdo que cumpra as obrigações aplicáveis.

Esta separação reduz interpretações incorretas. Um resultado técnico de uma mensagem curta de teste não demonstra necessariamente o comportamento de uma mensagem concatenada, com caracteres não GSM ou com um remetente diferente.

  • OTP: texto de teste curto, sem credenciais nem acesso real.
  • Transacional: evento fictício, identificável e sem informação sensível.
  • Marketing autorizado: apenas destinatários de teste autorizados e conteúdo em conformidade.
  • Não combine resultados entre categorias sem indicar que o caso de utilização mudou.

Selecione números de teste de forma responsável

Mantenha um inventário controlado de números de teste com autorização documentada para receber mensagens. Cada número deve ter um identificador interno, país, formato internacional, fonte da atribuição de rede e, sempre que possível, informação sobre se a receção pode ser observada num terminal controlado.

Não exponha números completos em relatórios alargados quando não for necessário. Utilize um identificador interno ou uma versão mascarada nos painéis de controlo e reserve os dados operacionais completos para os controlos de acesso adequados.

Revise o inventário periodicamente. Um número pode mudar de estado, de dispositivo ou de rede de subscrição. Se um resultado depender de uma condição que já não pode ser verificada, marque essa célula como pendente de atualização.

  • Identificador interno do número de teste.
  • Destino normalizado e país.
  • Rede atribuída e método ou data de atribuição.
  • Estado de autorização para testes.
  • Disponibilidade de terminal controlado para observação independente.
  • Última data de validação do inventário.

Crie casos que alterem uma variável de cada vez

Um caso base permite detetar diferenças sem confundir causas. Defina uma mensagem de teste legítima, reconhecível e sem informação sensível. Depois, crie variações controladas: altere a codificação, o comprimento, o remetente ou um elemento de conteúdo, mantendo as restantes variáveis constantes.

A codificação deve ser uma dimensão explícita. A especificação 3GPP TS 23.038 contempla, entre outras opções, o alfabeto GSM de 7 bits, dados de 8 bits e UCS2 de 16 bits. Também estabelece que, com o alfabeto GSM de 7 bits, uma mensagem pode conter até 160 caracteres. O comprimento, os caracteres utilizados e a concatenação podem alterar o tratamento técnico da mensagem.

Inclua casos de uma única parte e casos concatenados quando forem relevantes para o tráfego previsto. Registe a configuração solicitada e o resultado observado; não infira a codificação final a partir do texto visível no telemóvel.

  • Caso base: texto curto, identificável e sem caracteres ambíguos.
  • Variação de codificação: teste o conjunto de caracteres relevante para o seu tráfego.
  • Variação de comprimento: uma parte e, quando aplicável, mensagem concatenada.
  • Variação de remetente: avalie cada remetente que será utilizado.
  • Variação de conteúdo: altere apenas o elemento que pretende investigar.
  • Janela horária: repita em faixas definidas sem alterar as restantes condições.

O que medir em cada envio

O registo de cada envio deve permitir reconstruir a sequência completa. Conserve o momento de submissão, o resultado de aceitação, os identificadores de correlação devolvidos pela interface, todos os eventos de callback ou DLR e qualquer observação independente no terminal.

Os identificadores são essenciais. A especificação 3GPP TS 23.040 define elementos como TP-Message-Reference e SMS-STATUS-REPORT, bem como marcas temporais e estados associados. Numa integração HTTP ou SMPP, o identificador exposto por cada sistema pode ser diferente; documente como um identificador de cliente se correlaciona com o identificador do fornecedor, o callback e a observação de teste.

Registe estados temporários e falhas, e não apenas um resultado final simplificado. O fluxo SMS pode incluir indisponibilidade temporária, tentativas repetidas ou resultados posteriores. Eliminar estes eventos intermédios impede compreender se uma diferença resulta da aceitação, da entrega, da notificação ou do atraso do reporte.

  • Identificador interno da execução e versão do caso.
  • Marca temporal de submissão e resultado de aceitação.
  • Identificadores de correlação disponíveis.
  • Rota ou configuração avaliada.
  • Destino e remetente tal como foram submetidos.
  • Codificação, comprimento e número esperado de partes.
  • Eventos DLR ou callback: estado bruto, hora de receção e carga útil preservada.
  • Observação no terminal: sim, não ou não disponível; hora e método de observação.

DLR enviado não equivale a receção observada no terminal

Um DLR é uma evidência técnica valiosa, mas deve ser interpretado ao nível correto. A TS 23.040 distingue SMS-SUBMIT, SMS-DELIVER, SMS-DELIVER-REPORT e SMS-STATUS-REPORT. Estes mecanismos descrevem eventos, confirmações e resultados de transferência; não definem um evento de leitura pela pessoa destinatária.

Classifique a evidência para evitar afirmações excessivas. A aceitação confirma que uma interface aceitou o envio sob as suas condições. Um callback ou DLR confirma que foi recebido um reporte com um estado e uma hora. A observação independente num terminal controlado confirma que a mensagem foi vista nesse dispositivo e nesse momento, se a correlação com o envio for sólida. Nenhum nível prova, por si só, consentimento, identidade, titularidade do número ou leitura por um utilizador final.

Quando não existir observação no terminal, apresente o resultado como estado reportado, e não como receção comprovada. Quando existir, conserve o método de verificação e o identificador que associa a observação ao envio específico.

  • Nível 1: aceitação do envio pela interface.
  • Nível 2: DLR ou callback recebido e preservado.
  • Nível 3: receção observada num terminal de teste controlado.
  • Não equipare receção observada a leitura humana, consentimento ou identidade.
  • Não apresente um DLR como garantia universal de entrega.
FAQ

Perguntas frequentes

Quantos envios precisa de ter uma matriz de testes A2P SMS?

Não existe um número universal que torne uma amostra conclusiva. Defina-o de acordo com o risco operacional, os destinos, as redes, o tipo de mensagem e a variabilidade que necessita de observar. O importante é conservar o tamanho da amostra por célula e não comparar como equivalentes células com cobertura ou condições diferentes.

Um DLR de entregue prova que o SMS chegou ao telemóvel?

Não por si só. Um DLR é um reporte técnico de estado e deve ser preservado como evidência desse nível. A receção observada num terminal de teste controlado é uma evidência diferente. Nenhuma das duas prova, por si só, que uma pessoa leu a mensagem.

Deve ser incluído HLR Lookup na matriz?

Pode ser registado como uma fonte de contexto quando a sua utilização for autorizada, mas não deve ser tratado como prova de consentimento, identidade, titularidade do número, rota real ou entrega. A portabilidade móvel pode separar o intervalo numérico da rede de subscrição atual.

Porque devem ser testados caracteres e mensagens longas?

Porque a codificação e o alfabeto são variáveis técnicas explícitas. A TS 23.038 contempla GSM de 7 bits, dados de 8 bits e UCS2 de 16 bits, e o comprimento pode exigir concatenação. Um resultado com texto curto não valida automaticamente outro conteúdo ou um comprimento diferente.

Fontes consultadas

  1. ITU-T Recommendation E.164 — The international public telecommunication numbering planInternational Telecommunication Union
  2. 3GPP TS 23.040 / ETSI TS 123 040 V16.0.0 — Technical realization of the Short Message Service (SMS)ETSI / 3GPP
  3. 3GPP TS 23.038 / ETSI TS 123 038 V16.0.0 — Alphabets and language-specific informationETSI / 3GPP
  4. 3GPP TS 23.066 / ETSI TS 123 066 V16.0.0 — Support of Mobile Number Portability (MNP); Technical realization; Stage 2ETSI / 3GPP
  5. 3GPP specification portal — TS 23.040, Technical realization of the Short Message Service (SMS)3GPP
  6. 3GPP specification portal — SMS specifications including TS 23.038, TS 23.039 and TS 23.0403GPP