Zurück zum Blog Qualität und Vertrauen

So erstellen Sie eine A2P-SMS-Testmatrix nach Ziel, Netz, Absender und Nachrichtentyp

Ein operativer Leitfaden zur Gestaltung wiederholbarer A2P-SMS-Tests, zur Erfassung technischer Nachweise und zum Vergleich von Routen, ohne DLR mit der beobachteten Zustellung auf dem Endgerät zu verwechseln.

Operative A2P-SMS-Testmatrix mit Zielen, Mobilfunknetzen, Absendern und Zustellergebnissen

Warum ein einzelner Test keine SMS-Route validiert

Eine SMS, die an nur eine Nummer, in einem einzigen Netz und innerhalb eines einzelnen Zeitfensters gesendet wird, beschreibt nur diesen konkreten Fall. Sie belegt nicht, dass dieselbe Route bei anderen Ländern, Anschlussnetzen, Absendertypen, Kodierungen, Längen oder zulässigen Inhalten ein vergleichbares Verhalten zeigt.

Eine A2P-SMS-Testmatrix macht aus einer punktuellen Prüfung ein wiederholbares Bewertungsprogramm. Ihr Ziel ist nicht, Zustellung zu versprechen oder die Produktionsüberwachung zu ersetzen. Sie soll vergleichbare Nachweise liefern, um zu entscheiden, welche Routen genauer beobachtet werden sollten, welche Szenarien untersucht werden müssen und unter welchen Bedingungen eine Route bewertet werden kann, bevor sie mehr Traffic erhält.

Die zentrale Disziplin besteht darin, nicht über die Stichprobe hinaus zu extrapolieren. Ein günstiges Ergebnis in einem Ziel validiert kein ganzes Land; ein günstiges Ergebnis in einem Netz validiert nicht zwangsläufig ein anderes Netz; und ein positiver DLR beweist für sich genommen nicht, dass eine Person die Nachricht in der Benutzeroberfläche ihres Telefons gesehen hat.

  • Behandeln Sie jede Variablenkombination als eigenständige Testzelle.
  • Führen Sie eine eindeutig identifizierbare Version der Matrix und jedes ausgeführten Falls.
  • Vergleichen Sie nur gleichwertige Zellen oder dokumentieren Sie präzise, welche Variable sich geändert hat.
  • Trennen Sie beobachtete Fakten von vertraglichen, technischen oder kommerziellen Aussagen Dritter.
Warum ein einzelner Test keine SMS-Route validiert

Was die Matrix beantworten muss, bevor Traffic in die Produktion verlagert wird

Bevor Traffic ausgeweitet wird, muss die Matrix konkrete operative Fragen beantworten. Welche Kombinationen aus Ziel, Netz, Absender und Inhalt wurden getestet? Welche Ergebnisse wurden beobachtet? Wie viele vergleichbare Beobachtungen liegen vor? Welche Status wurden in welcher Reihenfolge und mit welcher Verzögerung empfangen? Gab es Unterschiede zwischen der ursprünglichen Annahme, Callbacks oder DLRs und der auf einem Testgerät beobachteten Zustellung?

Nicht jede Entscheidung benötigt denselben Nachweisgrad. Eine Route in der Explorationsphase kann kontrollierte Tests und eine manuelle Prüfung erfordern. Eine Route, die sensiblen Traffic wie OTP oder transaktionale Benachrichtigungen erhalten soll, benötigt eine Fallabdeckung, die ihrem tatsächlichen Einsatz näherkommt, mit internen Risikogrenzen, die vom verantwortlichen Team festgelegt werden.

Die Matrix muss auch ungetestete Bereiche sichtbar machen. Das Fehlen eines Ergebnisses darf nicht zu einer positiven Schlussfolgerung werden. Kennzeichnen Sie Zellen ohne Stichprobe als nicht bewertet, nicht als in Ordnung.

  • Abdeckung: Welche Ziele, Netze und Szenarien tatsächlich vertreten sind.
  • Wiederholbarkeit: Ob derselbe Fall erneut ausgeführt und verglichen werden kann.
  • Nachweise: Was auf der Plattform geschah, was der Anbieter meldete und was unabhängig beobachtet wurde.
  • Unsicherheit: Was wegen Stichprobengröße, fehlendem Testgerät oder wechselnden Bedingungen nicht geschlossen werden kann.
  • Entscheidung: Ausweiten, weiter beobachten, pausieren oder untersuchen.
Was die Matrix beantworten muss, bevor Traffic in die Produktion verlagert wird

Grundlegende Dimensionen einer A2P-SMS-Testmatrix

Das Design beginnt mit der Definition der Dimensionen, die das Ergebnis beeinflussen können. Normalisieren Sie die Zielnummer im internationalen Format und führen Sie das Land als explizites Feld. Die ITU-T-Empfehlung E.164 ist die geeignete Referenz zur Darstellung der internationalen Dimension der Nummerierung.

Leiten Sie den aktuellen Betreiber nicht allein aus dem Nummernbereich ab. Durch Mobilnummernportabilität kann eine MSISDN beim Wechsel des Anschlussnetzes erhalten bleiben. Daher sollte der, sofern vorhanden, aus dem Bereich abgeleitete Betreiber vom beobachteten oder durch ein autorisiertes Verfahren bestätigten Betreiber beziehungsweise Anschlussnetz unterschieden werden.

Erfassen Sie den Absender exakt so, wie er eingereicht wurde. Der Absendertyp kann alphanumerisch, numerisch oder ein anderes im anwendbaren technischen und regulatorischen Kontext zulässiges Format sein. Gehen Sie nicht davon aus, dass sich ein Absender selbst im selben Ziel genauso verhält wie ein anderer.

  • Land und Ziel im internationalen Format.
  • Mobilfunknetz oder Anschlussnetz mit Quelle der Zuordnung.
  • Nummerierungstyp und gegebenenfalls bekannter Portierungsstatus.
  • Zu bewertende Route, Verbindung oder Konfiguration.
  • Eingereichter Absender und dessen Format.
  • Nachrichtentyp: OTP, transaktional oder zulässiges Marketing.
  • Kodierung, Alphabet, Länge und Segmentierung.
  • Zeitfenster und Ausführungsdatum.

OTP, transaktionale Nachrichten und zulässiges Marketing trennen

OTP, transaktionale Nachrichten und zulässiges Marketing dürfen nicht in einer einzigen operativen Schlussfolgerung zusammengeführt werden. Obwohl alle SMS verwenden, unterliegen sie häufig unterschiedlichen Erwartungen an Inhalt, Aktualität und Nachverfolgbarkeit. Ein Test sollte den legitimen Anwendungsfall abbilden, der bewertet werden soll, ohne denselben Text wahllos für alle Szenarien wiederzuverwenden.

Verwenden Sie für OTP eindeutige Testtexte ohne personenbezogene Daten und ohne Codes, die realen Zugang gewähren. Erfassen Sie den Versandzeitpunkt und die Beobachtung auf dem Endgerät, sofern ein kontrolliertes Testgerät verfügbar ist. Verwenden Sie für transaktionale Nachrichten eine fiktive Benachrichtigung, die klar als Test gekennzeichnet ist. Beschränken Sie Marketingtests auf autorisierte Nummern und auf Inhalte, die den geltenden Verpflichtungen entsprechen.

Diese Trennung reduziert Fehlinterpretationen. Ein technisches Ergebnis einer kurzen Testnachricht belegt nicht zwangsläufig das Verhalten einer verketteten Nachricht, einer Nachricht mit Nicht-GSM-Zeichen oder eines anderen Absenders.

  • OTP: kurzer Testtext ohne Zugangsdaten oder realen Zugriff.
  • Transaktional: fiktives, erkennbares Ereignis ohne sensible Informationen.
  • Zulässiges Marketing: nur autorisierte Testempfänger und konforme Inhalte.
  • Führen Sie Ergebnisse aus verschiedenen Kategorien nicht zusammen, ohne anzugeben, dass sich der Anwendungsfall geändert hat.

Testnummern verantwortungsvoll auswählen

Führen Sie ein kontrolliertes Inventar von Testnummern mit dokumentierter Berechtigung zum Empfang von Nachrichten. Jede Nummer sollte eine interne Kennung, ein Land, das internationale Format, die Quelle der Netzzuordnung und, soweit möglich, Informationen darüber enthalten, ob der Empfang auf einem kontrollierten Endgerät beobachtet werden kann.

Legen Sie vollständige Nummern nicht in breit zugänglichen Berichten offen, wenn dies nicht erforderlich ist. Verwenden Sie in Dashboards eine interne Kennung oder eine maskierte Version und beschränken Sie vollständige operative Daten auf angemessene Zugriffskontrollen.

Überprüfen Sie das Inventar regelmäßig. Eine Nummer kann ihren Status, ihr Gerät oder ihr Anschlussnetz ändern. Wenn ein Ergebnis von einer Bedingung abhängt, die nicht mehr überprüft werden kann, kennzeichnen Sie diese Zelle als aktualisierungsbedürftig.

  • Interne Kennung der Testnummer.
  • Normalisiertes Ziel und Land.
  • Zugeordnetes Netz sowie Methode oder Datum der Zuordnung.
  • Autorisierungsstatus für Tests.
  • Verfügbarkeit eines kontrollierten Endgeräts für unabhängige Beobachtung.
  • Datum der letzten Inventarvalidierung.

Fälle so gestalten, dass sich jeweils nur eine Variable ändert

Ein Basisfall hilft, Unterschiede zu erkennen, ohne Ursachen zu vermischen. Definieren Sie eine legitime, erkennbare Testnachricht ohne sensible Informationen. Erstellen Sie anschließend kontrollierte Varianten: Ändern Sie die Kodierung, Länge, den Absender oder ein Inhaltselement, während alle anderen Variablen konstant bleiben.

Die Kodierung muss eine explizite Dimension sein. Die Spezifikation 3GPP TS 23.038 umfasst unter anderem das GSM-7-Bit-Alphabet, 8-Bit-Daten und 16-Bit-UCS2. Sie legt außerdem fest, dass eine Nachricht mit dem GSM-7-Bit-Alphabet bis zu 160 Zeichen enthalten kann. Länge, verwendete Zeichen und Verkettung können die technische Verarbeitung der Nachricht verändern.

Beziehen Sie einteilige und, sofern für den geplanten Traffic relevant, verkettete Fälle ein. Erfassen Sie die angeforderte Konfiguration und das beobachtete Ergebnis; leiten Sie die endgültige Kodierung nicht aus dem auf dem Telefon sichtbaren Text ab.

  • Basisfall: kurzer, erkennbarer Text ohne mehrdeutige Zeichen.
  • Kodierungsvariation: Testen Sie den für Ihren Traffic relevanten Zeichensatz.
  • Längenvariation: eine Nachrichteneinheit und, falls zutreffend, eine verkettete Nachricht.
  • Absendervariation: Bewerten Sie jeden Absender, der verwendet werden soll.
  • Inhaltsvariation: Ändern Sie nur das Element, das untersucht werden soll.
  • Zeitfenster: Wiederholen Sie Tests in definierten Zeitfenstern, ohne andere Bedingungen zu ändern.

Was bei jedem Versand gemessen werden sollte

Der Datensatz jedes Versands muss eine Rekonstruktion der vollständigen Abfolge ermöglichen. Bewahren Sie den Einreichungszeitpunkt, das Annahmeergebnis, die von der Schnittstelle zurückgegebenen Korrelationskennungen, alle Callback- oder DLR-Ereignisse sowie jede unabhängige Beobachtung auf dem Endgerät auf.

Kennungen sind entscheidend. Die Spezifikation 3GPP TS 23.040 definiert Elemente wie TP-Message-Reference und SMS-STATUS-REPORT sowie zugehörige Zeitstempel und Status. In einer HTTP- oder SMPP-Integration kann die von jedem System bereitgestellte Kennung unterschiedlich sein; dokumentieren Sie, wie eine Kundenkennung mit der Anbieterkennung, dem Callback und der Testbeobachtung korreliert wird.

Erfassen Sie Zwischenstatus und Fehler, nicht nur ein vereinfachtes Endergebnis. Der SMS-Ablauf kann vorübergehende Nichtverfügbarkeit, Wiederholungsversuche oder spätere Ergebnisse umfassen. Werden diese Zwischenereignisse gelöscht, lässt sich nicht nachvollziehen, ob ein Unterschied auf Annahme, Zustellung, Benachrichtigung oder einer verzögerten Meldung beruht.

  • Interne Ausführungskennung und Version des Testfalls.
  • Zeitstempel der Einreichung und Annahmeergebnis.
  • Verfügbare Korrelationskennungen.
  • Bewertete Route oder Konfiguration.
  • Ziel und Absender genau wie eingereicht.
  • Kodierung, Länge und erwartete Anzahl der Nachrichtenteile.
  • DLR- oder Callback-Ereignisse: Rohstatus, Empfangszeit und aufbewahrte Nutzlast.
  • Endgerätebeobachtung: ja, nein oder nicht verfügbar; Uhrzeit und Beobachtungsmethode.

Ein gesendeter DLR entspricht nicht der auf dem Endgerät beobachteten Zustellung

Ein DLR ist ein wertvoller technischer Nachweis, muss jedoch auf der richtigen Ebene interpretiert werden. TS 23.040 unterscheidet SMS-SUBMIT, SMS-DELIVER, SMS-DELIVER-REPORT und SMS-STATUS-REPORT. Diese Mechanismen beschreiben Ereignisse, Bestätigungen und Übertragungsergebnisse; sie definieren kein Leseereignis durch die empfangende Person.

Klassifizieren Sie Nachweise, um überzogene Aussagen zu vermeiden. Die Annahme bestätigt, dass eine Schnittstelle den Versand unter ihren Bedingungen akzeptiert hat. Ein Callback oder DLR bestätigt, dass ein Bericht mit einem Status und einer Uhrzeit empfangen wurde. Die unabhängige Beobachtung auf einem kontrollierten Endgerät bestätigt, dass die Nachricht auf diesem Gerät zu diesem Zeitpunkt sichtbar war, sofern die Korrelation mit dem Versand belastbar ist. Keine Ebene belegt für sich genommen Einwilligung, Identität, Inhaberschaft der Nummer oder das Lesen durch einen Endnutzer.

Wenn keine Endgerätebeobachtung vorliegt, berichten Sie das Ergebnis als gemeldeten Status, nicht als bestätigte Zustellung. Wenn eine Beobachtung vorliegt, bewahren Sie die Verifizierungsmethode und die Kennung auf, die die Beobachtung mit dem konkreten Versand verknüpft.

  • Stufe 1: Annahme des Versands durch die Schnittstelle.
  • Stufe 2: DLR oder Callback empfangen und aufbewahrt.
  • Stufe 3: Zustellung auf einem kontrollierten Testgerät beobachtet.
  • Setzen Sie beobachtete Zustellung nicht mit menschlichem Lesen, Einwilligung oder Identität gleich.
  • Stellen Sie einen DLR nicht als universelle Zustellgarantie dar.
FAQ

Häufige Fragen

Wie viele Sendungen benötigt eine A2P-SMS-Testmatrix?

Es gibt keine universelle Anzahl, die eine Stichprobe schlüssig macht. Definieren Sie sie anhand des operativen Risikos, der Ziele, Netze, Nachrichtentypen und der Variabilität, die Sie beobachten müssen. Entscheidend ist, die Stichprobengröße je Zelle zu dokumentieren und Zellen mit unterschiedlicher Abdeckung oder unterschiedlichen Bedingungen nicht als gleichwertig zu vergleichen.

Beweist ein DLR mit dem Status „zugestellt“, dass die SMS auf dem Telefon angekommen ist?

Nein, nicht für sich allein. Ein DLR ist ein technischer Statusbericht und sollte als Nachweis auf dieser Ebene aufbewahrt werden. Die auf einem kontrollierten Testgerät beobachtete Zustellung ist ein anderer Nachweis. Keiner der beiden belegt für sich genommen, dass eine Person die Nachricht gelesen hat.

Sollte ein HLR Lookup in die Matrix aufgenommen werden?

Er kann als Kontextquelle erfasst werden, sofern seine Nutzung autorisiert ist. Er darf jedoch nicht als Nachweis für Einwilligung, Identität, Nummerninhaberschaft, die tatsächliche Route oder Zustellung behandelt werden. Mobilnummernportabilität kann den Nummernbereich vom aktuellen Anschlussnetz trennen.

Warum sollten Zeichen und lange Nachrichten getestet werden?

Weil Kodierung und Alphabet explizite technische Variablen sind. TS 23.038 umfasst GSM 7-Bit, 8-Bit-Daten und UCS2 16-Bit, und die Länge kann eine Verkettung erfordern. Ein Ergebnis mit kurzem Text validiert nicht automatisch andere Inhalte oder eine andere Länge.

Verwendete Quellen

  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