Testes de aceitação de SMS A2P: valide a integração antes da produção

O que um teste de aceitação valida — e o que fica de fora

Um teste de aceitação permite verificar se a integração troca solicitações e respostas conforme o acordado: estabelece uma conexão, autentica, aceita ou rejeita envios de forma compreensível e processa os eventos posteriores previstos. O resultado se limita aos casos, destinos, remetentes, conteúdos e ambientes testados.

Isso não equivale a uma garantia de entrega futura nem demonstra o comportamento em outras operadoras, destinos ou condições. No SMPP, a resposta a submit_sm informa o resultado da solicitação; a entrega pode ocorrer mais tarde. Convém registrar separadamente a aceitação técnica, o estado posterior da mensagem e qualquer confirmação disponível.

• Defina quais componentes e comportamentos fazem parte da aceitação: conectividade, autenticação, formato, respostas, correlação e callbacks.
• Registre os aspectos que ficam de fora, como a entrega em destinos não testados ou o desempenho sob cargas diferentes das avaliadas.
• Combine o que significa «aprovado» para cada caso antes de começar.

Defina o escopo antes de enviar mensagens

Prepare um plano compartilhado pelas equipes de engenharia e operações e pelas partes responsáveis pela conexão. Especifique o ambiente de teste, os destinos autorizados, os remetentes e os conteúdos aprovados, além de indicar quem executa cada caso e quem interpreta o resultado. Use apenas números e mensagens cujo uso seja autorizado e esteja em conformidade com as regras aplicáveis.

Documente também as condições técnicas esperadas: protocolo, parâmetros aceitos, formato de endereços, codificação, limites acordados e mecanismo de recepção de respostas ou eventos. A estrutura da numeração internacional deve ser tratada de forma coerente com o escopo definido; não presuma que qualquer sequência com aparência de número será válida para a rota.

• Defina o ambiente, a janela de teste e os destinos e remetentes permitidos.
• Aprove o conteúdo e confirme que as mensagens são legítimas e autorizadas.
• Designe responsáveis pelo envio, monitoramento, análise de erros e decisão de aprovação.
• Registre as versões da configuração e os parâmetros relevantes para que o caso possa ser reproduzido.

Verifique conectividade, autenticação, formato e respostas

Em HTTP, verifique se a solicitação chega ao endpoint previsto e se o cliente interpreta tanto o código de status quanto o corpo da resposta. As classes de status HTTP descrevem o resultado da solicitação HTTP: um 2xx, por si só, não demonstra que o SMS chegou ao terminal. Verifique também o formato da resposta e como uma aceitação ou rejeição é representada segundo o contrato técnico.

Em SMPP, valide o estabelecimento da sessão e o bind, a troca de PDUs, as respostas e a manutenção da conexão. enquire_link permite verificar a comunicação no nível da aplicação. A resposta submit_sm_resp inclui o resultado da solicitação e, quando aplicável, um identificador da mensagem no SMSC; não a confunda com um relatório posterior de entrega.

Teste os formatos usados pela integração: endereço de destino, endereço de origem, codificação e comprimento da mensagem. O SMSC pode rejeitar ou truncar conteúdo que exceda os limites da rede ou da implementação. Verifique também se as rejeições são registradas e classificadas; no SMPP, command_status comunica o resultado da solicitação.

• Teste credenciais válidas e, em um ambiente controlado, o tratamento de autenticação inválida.
• Verifique formatos corretos e incorretos de endereços, codificação e comprimentos dentro do escopo acordado.
• Verifique respostas de aceitação e rejeição sem interpretá-las como prova de entrega.
• Em SMPP, valide o bind, as respostas associadas e a manutenção da sessão, inclusive os temporizadores configurados.

Verifique a correlação e o tratamento de callbacks

Cada envio e cada evento posterior devem poder ser associados de forma inequívoca dentro da aplicação. Em SMPP, sequence_number relaciona uma resposta à sua solicitação e deve ser preservado na resposta; além disso, as respostas podem chegar fora de ordem. Não baseie a correlação apenas na ordem de chegada.

Defina como processar callbacks ou recibos duplicados, tardios e fora de ordem. A deduplicação é uma decisão de implementação: não presuma que o protocolo garante que o evento será entregue uma única vez. Registre identificadores, estado recebido, marca temporal disponível e resultado do processamento, evitando que um evento repetido gere efeitos colaterais indesejados.

• Teste respostas que chegam fora de ordem e confirme que são associadas ao envio correto.
• Envie ou simule eventos repetidos e verifique a política de deduplicação acordada.
• Valide o tratamento de callbacks tardios, ausentes ou com identificadores que não possam ser correlacionados.
• Mantenha rastros suficientes para reconstruir a sequência sem expor credenciais.

Crie casos controlados para sucessos, rejeições e estados incertos

Um plano útil não se limita ao caso de sucesso. Inclua uma solicitação aceita, uma solicitação rejeitada devido a um parâmetro controlado, uma resposta tardia ou timeout e os diferentes resultados de entrega que a conexão permite observar. Para cada caso, registre a entrada, o resultado esperado, o resultado real e as evidências.

Trate um timeout no envio por HTTP como um resultado incerto: a solicitação pode ter sido processada mesmo que o cliente não tenha recebido uma resposta. Não tente novamente às cegas uma operação não idempotente, a menos que exista um mecanismo acordado para determinar se ela foi aplicada ou para evitar duplicações. Um timeout, por si só, não demonstra que o provedor rejeitou a mensagem.

Em SMPP, diferencie um erro de submissão comunicado na resposta de uma falha de entrega posterior. Registre ambos como resultados distintos e verifique como a aplicação os representa.

• Caso aceito: verifique a resposta, o identificador e o registro do envio.
• Caso rejeitado: verifique a classificação do erro e a ausência de uma falsa confirmação de entrega.
• Caso com timeout: marque o resultado como incerto e siga o procedimento acordado antes de tentar novamente.
• Caso com callback ausente, tardio ou duplicado: verifique os alertas, a conciliação e o tratamento operacional.
• Caso com mensagem ainda em trânsito: evite classificá-la prematuramente como entregue ou falha.

Separe a aceitação técnica da observação da entrega

Se precisar observar o resultado da entrega em SMPP, verifique se o SMSC Delivery Receipt é solicitado quando aplicável e se a integração pode receber o evento previsto, por exemplo, por meio de deliver_sm ou data_sm, conforme a implementação. A resposta imediata ao envio e o recibo posterior são etapas distintas.

Interprete cada DLR de acordo com quem o emite e o que ele indica. A especificação 3GPP distingue os relatórios do Service Centre, que confirmam o recebimento por esse centro, não pelo equipamento terminal, dos relatórios emitidos pela Mobile Station, que confirmam o recebimento pela estação móvel, mas não que alguém tenha visto ou lido a mensagem. Um estado como ENROUTE indica que ela continua em trânsito; não é uma confirmação final de entrega nem, por si só, uma falha.

A observação de algumas mensagens controladas descreve apenas esses casos no ambiente e no momento do teste. Não garante resultados futuros nem permite extrapolar automaticamente para outros destinos, operadoras ou condições.

• Separe o resultado HTTP ou SMPP da solicitação do estado posterior da entrega.
• Documente a origem e o escopo dos DLRs recebidos.
• Não apresente um DLR como prova de leitura ou de recebimento por uma pessoa.
• Defina como contabilizar estados não finais e recibos que não cheguem durante a janela de observação.

Defina critérios de aprovação e evidências

Os critérios devem ser observáveis e acordados antes da execução dos testes. Separe os requisitos de conectividade e processamento de solicitações dos requisitos de observação da entrega. Para cada um, indique qual resposta ou evento conta como aprovado, quais erros impedem a habilitação e quais resultados permanecem pendentes de análise.

Guarde o plano, a configuração relevante, as solicitações e respostas, os identificadores, os eventos recebidos e o resultado de cada caso. As evidências devem permitir reconstruir o que foi testado e o que não foi, sem transformar uma amostra controlada em uma afirmação geral sobre desempenho.

• Aprovação técnica: sessão ou endpoint operacional, autenticação e formatos em conformidade, respostas interpretadas e correlação correta.
• Aprovação operacional: rejeições, timeouts, duplicações e eventos tardios tratados conforme o procedimento acordado.
• Observação da entrega: documente separadamente o escopo, os estados, a origem do DLR e a janela de espera.
• Decisão final: registre os casos aprovados e pendentes, as exceções aceitas e os responsáveis que autorizam o avanço.

Habilite a produção gradualmente e com possibilidade de reversão

Após a aceitação, habilite o tráfego gradualmente, com limites e uma janela de observação definidos para o serviço. Não existe um limite universal de volume nem uma sequência de promoção estabelecida pelos padrões: combine os limites, os sinais de alerta e os responsáveis de acordo com o risco e a operação.

Antes do primeiro tráfego, determine quem pode interromper ou reverter a habilitação, quais condições acionam essa decisão e como serão gerenciadas as mensagens cujo resultado seja incerto. Monitore separadamente a conectividade, as respostas, as rejeições, os callbacks e os estados de entrega. A aprovação de um teste controlado autoriza apenas o escopo acordado; não garante o comportamento em qualquer condição futura.

• Defina os limites iniciais e os sinais de alerta antes de ativar o tráfego.
• Designe responsáveis pelo monitoramento e pela autoridade para interromper ou reverter a habilitação.
• Estabeleça como investigar timeouts e evitar tentativas que possam duplicar mensagens.
• Amplie o escopo somente após revisar as evidências e resolver os bloqueios acordados.