Tests de recette SMS A2P : valider l’intégration avant la mise en production

Ce que valide un test de recette et ce qu’il ne couvre pas

Un test de recette permet de vérifier que l’intégration échange des requêtes et des réponses comme convenu : elle établit une connexion, s’authentifie, accepte ou rejette les soumissions de manière compréhensible et traite les événements ultérieurs prévus. Son résultat se limite aux scénarios, destinations, expéditeurs, contenus et environnements qui ont été testés.

Cela ne constitue pas une garantie de livraison future et ne démontre pas le comportement sur d’autres opérateurs, destinations ou dans d’autres conditions. En SMPP, la réponse à submit_sm indique le résultat de la requête ; la livraison peut avoir lieu plus tard. Il est préférable d’enregistrer séparément la recette technique, l’état ultérieur du message et toute confirmation disponible.

• Définissez les composants et les comportements couverts par la recette : connectivité, authentification, format, réponses, corrélation et callbacks.
• Notez les aspects exclus, comme la livraison vers des destinations non testées ou les performances sous des charges différentes de celles des essais.
• Convenez de la signification de « réussi » pour chaque scénario avant de commencer.

Définissez le périmètre avant d’envoyer des messages

Préparez un plan partagé par l’ingénierie, les opérations et les parties responsables de la connexion. Précisez l’environnement de test, les destinations autorisées, les expéditeurs et les contenus approuvés, ainsi que les personnes chargées d’exécuter chaque scénario et d’interpréter son résultat. Utilisez uniquement des numéros et des messages dont l’utilisation est autorisée et conforme aux règles applicables.

Documentez également les conditions techniques attendues : protocole, paramètres pris en charge, format des adresses, encodage, limites convenues et mécanisme de réception des réponses ou événements. La structure de numérotation internationale doit être traitée conformément au périmètre défini ; ne supposez pas qu’une chaîne ayant l’apparence d’un numéro sera forcément valide pour la route.

• Fixez l’environnement, la période de test, les destinations et les expéditeurs autorisés.
• Faites approuver le contenu et confirmez que les messages sont légitimes et autorisés.
• Désignez les responsables de l’envoi, de la supervision, de l’analyse des erreurs et de la décision d’approbation.
• Consignez les versions de configuration et les paramètres pertinents afin de pouvoir reproduire le scénario.

Vérifiez la connectivité, l’authentification, le format et les réponses

En HTTP, vérifiez que la requête arrive au point de terminaison prévu et que le client interprète aussi bien le code d’état que le corps de la réponse. Les classes HTTP décrivent le résultat de la requête HTTP : un 2xx ne prouve pas, à lui seul, que le SMS est arrivé sur le terminal. Vérifiez également le format de la réponse et la manière dont une acceptation ou un rejet est représenté conformément au contrat technique.

En SMPP, validez l’établissement de la session et du bind, les échanges de PDU, les réponses et le maintien de la connexion. enquire_link permet de vérifier la communication au niveau applicatif. La réponse submit_sm_resp indique le résultat de la requête et, le cas échéant, un identifiant de message du SMSC ; ne la confondez pas avec un rapport de livraison ultérieur.

Testez les formats utilisés par l’intégration : adresse de destination, adresse d’origine, encodage et longueur du message. Le SMSC peut rejeter ou tronquer un contenu dépassant les limites autorisées par le réseau ou l’implémentation. Vérifiez également que les rejets sont enregistrés et classés ; en SMPP, command_status indique le résultat de la requête.

• Testez des identifiants valides et, dans un environnement contrôlé, le traitement d’une authentification invalide.
• Vérifiez les formats corrects et incorrects des adresses, l’encodage et les longueurs, dans le périmètre convenu.
• Vérifiez les réponses d’acceptation et de rejet sans les interpréter comme une preuve de livraison.
• En SMPP, validez le bind, les réponses associées et le maintien de la session, y compris les délais configurés.

Vérifiez la corrélation et le traitement des callbacks

Chaque envoi et chaque événement ultérieur doivent pouvoir être associés sans ambiguïté dans l’application. En SMPP, sequence_number relie une réponse à sa requête et doit être conservé dans la réponse ; les réponses peuvent aussi arriver dans le désordre. Ne fondez pas la corrélation uniquement sur l’ordre d’arrivée.

Définissez le traitement des callbacks ou accusés de réception en double, tardifs et désordonnés. La déduplication est un choix d’implémentation : il ne faut pas supposer que le protocole garantit la réception d’un événement une seule fois. Enregistrez les identifiants, l’état reçu, l’horodatage disponible et le résultat du traitement, en évitant qu’un événement répété entraîne des effets indésirables.

• Testez des réponses arrivant dans le désordre et vérifiez qu’elles sont associées au bon envoi.
• Envoyez ou simulez des événements répétés et vérifiez la politique de déduplication convenue.
• Validez le traitement des callbacks tardifs, absents ou associés à des identifiants impossibles à corréler.
• Conservez suffisamment de traces pour reconstituer la séquence sans exposer d’identifiants.

Concevez des scénarios contrôlés pour les réussites, les rejets et les états incertains

Un plan utile ne se limite pas au scénario nominal. Incluez une requête acceptée, une requête rejetée en raison d’un paramètre contrôlé, une réponse tardive ou un délai d’attente dépassé, ainsi que les différents résultats de livraison que la connexion permet d’observer. Pour chaque scénario, notez les données d’entrée, le résultat attendu, le résultat réel et les preuves.

Considérez l’expiration du délai d’attente d’un envoi HTTP comme un résultat incertain : la requête a pu être traitée même si le client n’a pas reçu de réponse. Ne relancez pas à l’aveugle une opération non idempotente, sauf s’il existe un mécanisme convenu permettant de déterminer si elle a été exécutée ou d’éviter les doublons. Un délai d’attente dépassé ne prouve pas, à lui seul, que le fournisseur a rejeté le message.

En SMPP, distinguez une erreur de soumission indiquée dans la réponse d’un échec de livraison ultérieur. Consignez ces deux résultats séparément et vérifiez la manière dont l’application les représente.

• Scénario accepté : vérifiez la réponse, l’identifiant et l’enregistrement de l’envoi.
• Scénario rejeté : vérifiez la classification de l’erreur et l’absence de fausse confirmation de livraison.
• Scénario avec délai d’attente dépassé : marquez le résultat comme incertain et suivez la procédure convenue avant toute nouvelle tentative.
• Scénario avec callback absent, tardif ou en double : vérifiez les alertes, le rapprochement et le traitement opérationnel.
• Scénario avec message encore en transit : évitez de le classer prématurément comme livré ou en échec.

Distinguez la recette technique du suivi de la livraison

Si vous devez observer le résultat de livraison en SMPP, vérifiez que le SMSC Delivery Receipt est demandé lorsque cela convient et que l’intégration peut recevoir l’événement prévu, par exemple au moyen de deliver_sm ou data_sm selon l’implémentation. La réponse immédiate à l’envoi et l’accusé de réception ultérieur sont deux étapes distinctes.

Interprétez chaque DLR selon son émetteur et sa signification. La spécification 3GPP distingue les rapports du Service Centre, qui confirment la réception par ce centre et non par le terminal, des rapports émis par la Mobile Station, qui confirment la réception par la station mobile, mais ne signifient pas qu’une personne a vu ou lu le message. Un état tel que ENROUTE indique que le message est toujours en transit ; il ne constitue ni une confirmation définitive de livraison ni, à lui seul, un échec.

L’observation de quelques messages contrôlés ne décrit que ces scénarios, dans l’environnement et au moment du test. Elle ne garantit pas les résultats futurs et ne permet pas d’extrapoler automatiquement à d’autres destinations, opérateurs ou conditions.

• Séparez le résultat de la requête HTTP ou SMPP de l’état ultérieur de livraison.
• Documentez la source et la portée des DLR reçus.
• Ne présentez pas un DLR comme une preuve de lecture ou de réception par une personne.
• Définissez la façon de comptabiliser les états non définitifs et les accusés de réception qui n’arrivent pas pendant la période observée.

Définissez les critères d’approbation et les preuves

Les critères doivent être observables et convenus avant l’exécution des tests. Séparez les exigences de connectivité et de traitement des requêtes de celles concernant le suivi de la livraison. Pour chaque exigence, indiquez quelle réponse ou quel événement vaut approbation, quelles erreurs empêchent l’activation et quels résultats restent à analyser.

Conservez le plan, la configuration pertinente, les requêtes et les réponses, les identifiants, les événements reçus et le résultat de chaque scénario. Les preuves doivent permettre de reconstituer ce qui a été testé et ce qui ne l’a pas été, sans transformer un échantillon contrôlé en affirmation générale sur les performances.

• Approbation technique : session ou point de terminaison opérationnel, authentification et formats conformes, réponses interprétées et corrélation correcte.
• Approbation opérationnelle : rejets, délais d’attente dépassés, doublons et événements tardifs traités conformément à la procédure convenue.
• Suivi de la livraison : périmètre, états, source du DLR et période d’attente documentés séparément.
• Décision finale : consignez les éléments approuvés ou en attente, les exceptions acceptées et les responsables autorisant la poursuite.

Activez la production progressivement, avec une possibilité de retour arrière

Après la recette, activez progressivement le trafic, avec des limites et une période de suivi définies pour le service concerné. Les normes ne fixent ni seuil de volume universel ni séquence de mise en service : convenez des limites, des alertes et des responsables en fonction des risques et des opérations.

Avant le premier trafic, déterminez qui peut interrompre ou annuler l’activation, quelles conditions déclenchent cette décision et comment gérer les messages dont le résultat est incertain. Surveillez séparément la connectivité, les réponses, les rejets, les callbacks et les états de livraison. La validation d’un test contrôlé autorise uniquement le périmètre convenu ; elle ne garantit pas le comportement dans toutes les conditions futures.

• Définissez les limites initiales et les signaux d’alerte avant d’activer le trafic.
• Désignez les responsables de la supervision et les personnes autorisées à interrompre ou à annuler l’activation.
• Établissez la marche à suivre pour examiner les délais d’attente dépassés et éviter les nouvelles tentatives susceptibles de dupliquer des messages.
• Élargissez le périmètre uniquement après examen des preuves et résolution des blocages convenus.