Abnahmetests für A2P-SMS: Integration vor dem Produktivstart prüfen

Was ein Abnahmetest prüft – und was nicht

Mit einem Abnahmetest lässt sich prüfen, ob die Integration Anfragen und Antworten wie vereinbart austauscht: Sie stellt eine Verbindung her, authentifiziert sich, nimmt Sendungen an oder lehnt sie verständlich ab und verarbeitet die vorgesehenen Folgeereignisse. Das Ergebnis gilt nur für die getesteten Fälle, Ziele, Absender, Inhalte und Umgebungen.

Ein Abnahmetest ist weder eine Garantie für künftige Zustellungen noch ein Nachweis für das Verhalten bei anderen Mobilfunkbetreibern, Zielen oder Bedingungen. Bei SMPP gibt die Antwort auf submit_sm Auskunft über das Ergebnis der Anfrage; die Zustellung kann später erfolgen. Die technische Annahme, der spätere Nachrichtenstatus und verfügbare Bestätigungen sollten getrennt erfasst werden.

• Legen Sie fest, welche Komponenten und Verhaltensweisen zur Abnahme gehören: Konnektivität, Authentifizierung, Format, Antworten, Zuordnung und Callbacks.
• Halten Sie fest, was nicht abgedeckt ist, etwa die Zustellung an nicht getestete Ziele oder die Leistung unter anderen als den geprüften Lastbedingungen.
• Vereinbaren Sie vor Testbeginn, was für jeden Fall als „bestanden“ gilt.

Legen Sie den Umfang fest, bevor Sie Nachrichten senden

Erstellen Sie einen gemeinsamen Plan für Entwicklung, Betrieb und die für die Verbindung zuständigen Parteien. Legen Sie die Testumgebung, zugelassene Ziele, Absender und freigegebene Inhalte fest. Bestimmen Sie außerdem, wer die einzelnen Fälle ausführt und wer die Ergebnisse bewertet. Verwenden Sie nur Nummern und Nachrichten, deren Einsatz zulässig ist und den geltenden Regeln entspricht.

Dokumentieren Sie auch die erwarteten technischen Bedingungen: Protokoll, unterstützte Parameter, Adressformat, Kodierung, vereinbarte Grenzen und Verfahren für den Empfang von Antworten oder Ereignissen. Die internationale Nummernstruktur muss zum festgelegten Umfang passen. Gehen Sie nicht davon aus, dass jede Zeichenfolge, die wie eine Nummer aussieht, für die Route gültig ist.

• Legen Sie Umgebung, Testzeitraum sowie zulässige Ziele und Absender fest.
• Geben Sie die Inhalte frei und bestätigen Sie, dass die Nachrichten legitim und autorisiert sind.
• Bestimmen Sie Verantwortliche für den Versand, die Überwachung, die Fehleranalyse und die Abnahmeentscheidung.
• Dokumentieren Sie Konfigurationsversionen und relevante Parameter, damit sich der Testfall wiederholen lässt.

Prüfen Sie Konnektivität, Authentifizierung, Formate und Antworten

Prüfen Sie bei HTTP, ob die Anfrage den vorgesehenen Endpunkt erreicht und der Client sowohl den Statuscode als auch den Antwortinhalt korrekt auswertet. HTTP-Statusklassen beschreiben das Ergebnis der HTTP-Anfrage: Ein 2xx-Status allein beweist nicht, dass die SMS das Endgerät erreicht hat. Prüfen Sie außerdem das Antwortformat und wie eine Annahme oder Ablehnung gemäß der technischen Vereinbarung dargestellt wird.

Validieren Sie bei SMPP den Sitzungsaufbau und den Bind, den Austausch von PDUs, die Antworten und die Aufrechterhaltung der Verbindung. enquire_link kann die Kommunikation auf Anwendungsebene prüfen. Die Antwort submit_sm_resp enthält das Ergebnis der Anfrage und gegebenenfalls eine Nachrichten-ID des SMSC; verwechseln Sie sie nicht mit einem späteren Zustellbericht.

Testen Sie die von der Integration verwendeten Formate: Zieladresse, Absenderadresse, Kodierung und Nachrichtenlänge. Das SMSC kann Inhalte ablehnen oder abschneiden, wenn sie die vom Netz oder der Implementierung zugelassenen Grenzen überschreiten. Prüfen Sie außerdem, ob Ablehnungen protokolliert und klassifiziert werden. Bei SMPP übermittelt command_status das Ergebnis der Anfrage.

• Testen Sie gültige Zugangsdaten und in einer kontrollierten Umgebung auch den Umgang mit ungültigen Authentifizierungsdaten.
• Prüfen Sie korrekte und fehlerhafte Adressformate, Kodierungen und Nachrichtenlängen im vereinbarten Umfang.
• Verifizieren Sie Annahme- und Ablehnungsantworten, ohne sie als Zustellnachweis zu interpretieren.
• Prüfen Sie bei SMPP den Bind, die zugehörigen Antworten und den Sitzungserhalt einschließlich der konfigurierten Zeitgeber.

Prüfen Sie die Zuordnung und Verarbeitung von Callbacks

Jede Sendung und jedes Folgeereignis muss sich innerhalb der Anwendung eindeutig zuordnen lassen. Bei SMPP verknüpft sequence_number eine Antwort mit ihrer Anfrage und muss in der Antwort erhalten bleiben. Außerdem können Antworten in anderer Reihenfolge eintreffen. Richten Sie die Zuordnung daher nicht allein nach der Eingangsreihenfolge aus.

Legen Sie fest, wie doppelte, verspätete und ungeordnet eintreffende Callbacks oder Empfangsbestätigungen verarbeitet werden. Deduplizierung ist eine Implementierungsentscheidung: Gehen Sie nicht davon aus, dass das Protokoll eine einmalige Zustellung des Ereignisses garantiert. Protokollieren Sie verfügbare Kennungen, empfangenen Status, Zeitstempel und Verarbeitungsergebnis. Verhindern Sie, dass ein wiederholtes Ereignis unerwünschte Nebenwirkungen auslöst.

• Testen Sie Antworten, die in anderer Reihenfolge eintreffen, und bestätigen Sie, dass sie der richtigen Sendung zugeordnet werden.
• Senden oder simulieren Sie wiederholte Ereignisse und prüfen Sie die vereinbarte Deduplizierungsrichtlinie.
• Validieren Sie den Umgang mit verspäteten oder ausbleibenden Callbacks sowie mit Kennungen, die sich nicht zuordnen lassen.
• Bewahren Sie genügend Protokolldaten auf, um den Ablauf nachvollziehen zu können, ohne Zugangsdaten offenzulegen.

Entwerfen Sie kontrollierte Testfälle für Annahmen, Ablehnungen und unklare Zustände

Ein sinnvoller Testplan beschränkt sich nicht auf den Erfolgsfall. Nehmen Sie eine angenommene Anfrage, eine aufgrund eines kontrollierten Parameters abgelehnte Anfrage, eine verspätete Antwort oder einen Timeout sowie die verschiedenen beobachtbaren Zustellergebnisse auf. Dokumentieren Sie für jeden Fall die Eingabe, das erwartete Ergebnis, das tatsächliche Ergebnis und die Nachweise.

Behandeln Sie einen HTTP-Sendetimeout als unklaren Zustand: Die Anfrage könnte verarbeitet worden sein, obwohl der Client keine Antwort erhalten hat. Wiederholen Sie einen nicht idempotenten Vorgang nicht blind, sofern es keinen vereinbarten Mechanismus gibt, um festzustellen, ob er ausgeführt wurde oder um Duplikate zu vermeiden. Ein Timeout beweist für sich genommen nicht, dass der Anbieter die Nachricht abgelehnt hat.

Unterscheiden Sie bei SMPP einen in der Antwort gemeldeten Übermittlungsfehler von einem späteren Zustellfehler. Erfassen Sie beides als unterschiedliche Ergebnisse und prüfen Sie, wie die Anwendung sie darstellt.

• Angenommener Fall: Antwort, Kennung und Protokollierung der Sendung prüfen.
• Abgelehnter Fall: Fehlerklassifizierung und das Ausbleiben einer falschen Zustellbestätigung prüfen.
• Timeout-Fall: Ergebnis als unklar kennzeichnen und vor einem erneuten Versuch das vereinbarte Verfahren befolgen.
• Fall mit ausbleibendem, verspätetem oder doppeltem Callback: Alarmierung, Abgleich und betriebliche Verarbeitung prüfen.
• Nachricht noch unterwegs: Sie nicht vorschnell als zugestellt oder fehlgeschlagen einstufen.

Trennen Sie die technische Abnahme von der Beobachtung der Zustellung

Wenn Sie Zustellergebnisse bei SMPP beobachten müssen, prüfen Sie, ob bei Bedarf ein SMSC Delivery Receipt angefordert wird und ob die Integration das vorgesehene Ereignis empfangen kann, beispielsweise über deliver_sm oder data_sm, je nach Implementierung. Die unmittelbare Antwort auf den Sendeversuch und der spätere Empfangsbericht sind unterschiedliche Schritte.

Interpretieren Sie jeden DLR im Hinblick darauf, wer ihn ausstellt und was er aussagt. Die 3GPP-Spezifikation unterscheidet Berichte des Service Centre, die den Empfang durch dieses Zentrum und nicht durch das Endgerät bestätigen, von Berichten der Mobile Station, die den Empfang durch die Mobilstation bestätigen, nicht aber, dass eine Person die Nachricht gesehen oder gelesen hat. Ein Status wie ENROUTE bedeutet, dass die Nachricht noch unterwegs ist; er ist weder eine abschließende Zustellbestätigung noch für sich genommen ein Fehler.

Die Beobachtung einiger kontrollierter Nachrichten beschreibt nur diese Fälle in der Testumgebung und zum Testzeitpunkt. Sie garantiert keine künftigen Ergebnisse und lässt sich nicht automatisch auf andere Ziele, Betreiber oder Bedingungen übertragen.

• Trennen Sie das Ergebnis der HTTP- oder SMPP-Anfrage vom späteren Zustellstatus.
• Dokumentieren Sie Quelle und Aussageumfang der empfangenen DLRs.
• Stellen Sie einen DLR nicht als Nachweis dafür dar, dass ein Mensch die Nachricht gelesen oder empfangen hat.
• Legen Sie fest, wie nicht finale Statusmeldungen und Empfangsbestätigungen behandelt werden, die innerhalb des Beobachtungszeitraums ausbleiben.

Legen Sie Abnahmekriterien und Nachweise fest

Die Kriterien müssen beobachtbar und vor der Durchführung der Tests vereinbart sein. Trennen Sie Anforderungen an Konnektivität und Anfrageverarbeitung von Anforderungen an die Beobachtung der Zustellung. Geben Sie für jeden Bereich an, welche Antwort oder welches Ereignis als bestanden gilt, welche Fehler die Freischaltung verhindern und welche Ergebnisse noch analysiert werden müssen.

Bewahren Sie den Plan, die relevante Konfiguration, Anfragen und Antworten, Kennungen, empfangene Ereignisse und die Ergebnisse der einzelnen Fälle auf. Die Nachweise müssen nachvollziehbar machen, was getestet wurde und was nicht, ohne aus einer kontrollierten Stichprobe eine allgemeine Leistungsbehauptung abzuleiten.

• Technische Abnahme: Endpunkt oder Sitzung ist betriebsbereit, Authentifizierung und Formate entsprechen den Vorgaben, Antworten werden ausgewertet und Ereignisse korrekt zugeordnet.
• Betriebliche Abnahme: Ablehnungen, Timeouts, Duplikate und verspätete Ereignisse werden gemäß dem vereinbarten Verfahren behandelt.
• Beobachtung der Zustellung: Umfang, Statusmeldungen, DLR-Quelle und Wartezeitraum sind getrennt dokumentiert.
• Abschlussentscheidung: Bestandene und ausstehende Punkte, akzeptierte Ausnahmen und die für die Freigabe verantwortlichen Personen werden festgehalten.

Schalten Sie den Produktivbetrieb schrittweise frei und halten Sie einen Rückweg bereit

Schalten Sie den Verkehr nach der Abnahme schrittweise frei und legen Sie für den jeweiligen Dienst Grenzwerte sowie einen Beobachtungszeitraum fest. Es gibt keinen universellen Volumengrenzwert und keine standardmäßig festgelegte Freigabesequenz: Vereinbaren Sie Grenzwerte, Warnsignale und Verantwortliche entsprechend dem Risiko und dem Betriebsablauf.

Legen Sie vor dem ersten Produktivverkehr fest, wer die Freischaltung stoppen oder zurücknehmen darf, welche Bedingungen diese Entscheidung auslösen und wie mit Nachrichten umgegangen wird, deren Ergebnis unklar ist. Überwachen Sie Konnektivität, Antworten, Ablehnungen, Callbacks und Zustellstatus getrennt. Die Abnahme eines kontrollierten Tests gibt nur den vereinbarten Umfang frei und garantiert kein Verhalten unter beliebigen künftigen Bedingungen.

• Legen Sie vor der Freischaltung anfängliche Grenzwerte und Warnsignale fest.
• Bestimmen Sie Verantwortliche für die Überwachung und Personen mit der Befugnis, den Betrieb zu stoppen oder zurückzunehmen.
• Legen Sie fest, wie Timeouts untersucht und erneute Versuche mit möglichen Nachrichtenduplikaten vermieden werden.
• Erweitern Sie den Umfang erst, nachdem Sie die Nachweise geprüft und die vereinbarten Blocker behoben haben.