So verlieren Sie kein Geld in der Black Box: Abrechnungstestmethoden

Die Validierung kostenpflichtiger Dienste ist eines der wichtigsten technischen Probleme beim Testen von Badoo. Unsere Anwendung ist in 70 Zahlungsanbieter in 250 Ländern der Welt integriert, und ein Fehler in mindestens einem von ihnen kann zu unvorhersehbaren Konsequenzen führen.

In diesem Artikel werde ich über die Testmethoden sprechen, die wir in Badoo verwenden, und über die Grenzen der Anwendbarkeit dieser Methoden - die Testphasen, in denen sie am effektivsten sind.

Dieser Artikel ist nützlich für Tester, Entwickler und Produktmanager, deren Projekte bereits in Zahlungsanbieter integriert sind oder deren Integrationsprozess gerade erst beginnt. Wenn Sie bei Ihrer Arbeit vor dem Problem stehen, Testmethoden für solche Integrationen auszuwählen, sind Sie bei cat willkommen!




Mein Name ist Vladimir Solodov, ich bin Billing QA Engineer bei Badoo: Ich beschäftige mich mit der Überprüfung von Testintegrationen und der Zahlungsabwicklung. Mein Kollege Viktor Koronevich half mir bei der Vorbereitung des Textes: Zusammen mit ihm haben wir auf der Heisenbug-Konferenz einen Bericht erstellt ( Video ). In dem Artikel haben wir den Beschreibungsbereich auf alle Integrationen mit Zahlungsanbietern erweitert, die in Badoo verwendet werden, und die Praxis des Entfernens externer Abhängigkeiten detaillierter klassifiziert und beschrieben.

Am Beispiel von Geschäftsfallstudien erkläre ich Ihnen, warum Sie dem Testen kostenpflichtiger Dienste mehr Aufmerksamkeit schenken sollten und wie Sie Probleme nicht verschlimmern können, wenn sie dennoch auftreten. Anschließend werden die technischen Probleme beim Testen der Integration und Möglichkeiten zu deren Lösung beschrieben.

Der zweite Teil des Artikels, in dem wir mehr über die Automatisierung des Testens von kostenpflichtigen Diensten in iOS-Anwendungen sprechen, ist hier .

Lass uns gehen!

Besonderheiten des Abrechnungstests

In der Regel besteht das Ziel eines Unternehmens darin, Umsatz zu generieren. In Badoo, einem sozialen Netzwerk für Dating, wird das Einkommen durch Kredite und Prämienabonnements verdient. Kredite sind die interne Währung von Badoo. Mit ihrer Hilfe können Sie beispielsweise Ihr Profil in den Suchergebnissen an erster Stelle erhöhen, einem anderen Benutzer ein Geschenk machen und vieles mehr. Das Premium-Abonnement ist für einen bestimmten Zeitraum gültig und bietet Ihnen mehrere Optionen gleichzeitig: Aktivieren Sie den "unsichtbaren" Modus, sehen Sie Personen, die Interesse an Ihnen gezeigt haben, bestätigen Sie die Authentizität Ihres Kontos und vieles mehr.

Damit diese kostenpflichtigen Dienste funktionieren, verwenden wir Integrationen mit mehr als 70 Zahlungsanbietern. Die Wahl des Anbieters hängt von der Plattform, dem Land, dem Gerät, dem Mobilfunkbetreiber und anderen Faktoren ab. Daher ist das Problem des Testens kostenpflichtiger Dienste sehr dringend.

Überlegen Sie zunächst, warum das Testen kostenpflichtiger Dienste mit besonderer Aufmerksamkeit angegangen werden sollte. Es gibt zwei Gründe.

1. Abrechnungsfehler sind für das Geschäft von entscheidender Bedeutung.

Das erste Problem ist der Ruf. Der Benutzer, der für den Dienst bezahlt hat, wird empfindlicher (und weniger tolerant) gegenüber Fehlern in der Anwendung. Jedes Feedback im öffentlichen Raum, sei es eine Überprüfung einer Blog-Anwendung oder ein Kommentar im App Store oder bei Google Play, von einem Benutzer, der auf einen Fehler in einem kostenpflichtigen Dienst stößt, ist emotionaler - dies ist ein Faktor, der zu Reputationsverlusten führt.

Das zweite Problem besteht darin, dass Sie, sobald Sie von einem Benutzer Geld für einen Dienst erhalten, Gegenstand eines Gesetzes werden, das den Verbraucher des Dienstes schützt. Und Reputationsverluste können leicht zu finanziellen werden.

Unternehmen verlieren auf drei Arten Geld.

Der erste Weg sind Rückerstattungen . Angenommen, ein Benutzer stellt fest, dass Sie ihm einen Dienst verkauft haben, der seinen Erwartungen nicht ganz entspricht. In diesem Fall wird er Ihr Support-Team kontaktieren. Die Mitarbeiter führen eine Untersuchung durch und stellen fest, dass die Erwartungen des Benutzers aufgrund eines Fehlers in der Anwendung tatsächlich nicht erfüllt wurden. Sie veranlassen eine Rückerstattung. In diesem Fall gibt es eine Rückerstattung: Infolgedessen ist das Unternehmen mit entgangenen Gewinnen konfrontiert, und dies ist der harmloseste Weg, um Geld zu verlieren.

Der zweite Weg sind Rückbuchungen . Angenommen, die gleiche Situation ist aufgetreten, nur der Benutzer hat sich nicht an Ihren Support-Service gewandt, sondern an die Bank, die ihm die Karte ausgestellt hat, oder an den Zahlungsanbieter. Bank / Anbieter veranlasst eine Rückerstattung. In diesem Fall handelt es sich um eine Rückbuchung. Die Gefahr für das Geschäft besteht hier nicht nur in entgangenen Gewinnen. Nach einer bestimmten Anzahl von Rückbuchungen erhält das Unternehmen eine Geldstrafe und seine Risikobewertung nimmt ab. Die Herabstufung führt wiederum zu einem Anstieg der Kosten für die Dienstleistungen von Zahlungsanbietern.

Der dritte Weg - Klagen (Ansprüche) . In den am meisten vernachlässigten Fällen können Klagen (einschließlich kollektiver) stattfinden, die zu den schwerwiegendsten Konsequenzen führen. Nach einer Klage der Regulierungsbehörde von Ofgem war British Gas 2015 gezwungen, Nutzern, die aufgrund eines Fehlers im Ladesystem eine höhere Gebühr erhoben, eine Entschädigung in Höhe von mehreren Millionen Dollar zu zahlen. Lesen Sie hier mehr darüber.

2. Zum Testen von Integrationen werden Wissen und Know-how benötigt.

Teams, die gerade erst mit der Integration mit Zahlungsanbietern beginnen, sind häufig mit diesem Problem konfrontiert. Da sie nicht alle möglichen Abrechnungsfälle kennen, übersehen sie wichtige Nuancen, wenn sie die Reaktion des Systems auf Benachrichtigungen von Zahlungsanbietern erkennen.

Dies kann zu unvorhersehbaren Konsequenzen führen - von entgangenen Gewinnen bis zu unzufriedenen Benutzern.

Schauen wir uns das Schema an, in dem die Arten der kostenpflichtigen Dienste aufgeführt sind, und betrachten wir das Problem genauer.


Abbildung 1. Mögliche Abrechnungsfälle

Es gibt drei Hauptfälle: einen Fehler, eine erfolgreiche Zahlung und eine Rückerstattung an den Benutzer. Aber jeder Fall hat Details, jeder Fall muss Ihr System anders behandeln.

Fehler können kritisch und unkritisch sein. Ein Benachrichtigungsfehler kann auf eine nicht kritische Blockierung der Zahlungsmethode des Benutzers zurückgeführt werden, wenn der Zahlungsanbieter über den Mangel an Guthaben auf dem Benutzerkonto informiert und kritisch. Und wenn Sie im ersten Fall versuchen können, später zu zahlen, dann im zweiten Fall - es wäre schön herauszufinden, warum die Methode blockiert ist. Möglicherweise wurde der Benutzer bei Betrug bemerkt und Sie sollten bei seinen Transaktionen vorsichtiger sein.

Rückerstattungen . Sie wissen bereits, dass es zwei Arten von Rückgaben gibt: Rückerstattungen und Rückbuchungen. Ihr System muss anders darauf reagieren. Beispielsweise ist es nach einer Rückbuchung sinnvoll, einige Funktionen Ihrer Anwendung für den Benutzer zu blockieren, da die Rückbuchung eine der beliebtesten Betrugsmethoden ist.

Eine erfolgreiche Zahlung kann eine einmalige Zahlung oder ein Abonnement sein.

Einmalige Zahlungen können verbrauchbar und nicht verbrauchbar sein. Ein Beispiel für eine ausgegebene Zahlung haben wir ganz am Anfang des Artikels untersucht - dies sind Kredite in Badoo. Ein Beispiel für eine nicht entbehrliche Zahlung kann aus Spielen gegeben werden. Angenommen, Sie haben einen Charakter, den Sie spielen. Sie wollen für ihn Superkräfte kaufen, die es schon seit einiger Zeit gibt. In diesem Fall gehört der Kauf zur Klasse der nicht verbrauchbaren Zahlungen.

Abonnements Hier ist die größte Vielfalt von Fällen. Zusätzlich zum erstmaligen Kauf eines Abonnements haben Sie möglicherweise:

• Verlängerung eines Abonnements (Verlängerung);
  
• Abonnement schließen (Abonnement kündigen);
  
• Testabonnement (Testversion);
  
• Nachfrist-Abonnement: Wenn wir das Abonnement nicht verlängern können und erneut versuchen, für einen als Nachfrist bezeichneten Zeitraum erneut zu zahlen. Für den Benutzer sieht die Nachfrist so aus. Angenommen, Sie haben ein monatliches Zeitungsabonnement gekauft. Das Unternehmen, das Ihnen Zeitungen sendet, versucht, die Zahlung für den nächsten Abonnementmonat nach dem Ende des ersten Monats abzuschreiben, kann dies jedoch nicht tun (aufgrund einer Kartensperre, fehlender Mittel auf dem Konto usw.). Wenn die Gültigkeitsdauer der Nachfrist zehn Tage beträgt, versucht das Unternehmen während dieser Zeit, die Zahlung abzuschreiben, während das Abonnement gültig bleibt. Wenn das Unternehmen das Geld nicht abschreiben kann, wird das Abonnement gekündigt. Wenn dies der Fall ist, wird das Abonnement ab dem Datum der letzten Zahlung verlängert.
  
• Teilzahlung (Teilabrechnung). Mit PayPal können Sie beispielsweise Teilzahlungen vornehmen, wenn das Konto des Benutzers nicht über genügend Guthaben verfügt (Teilzahlung), oder die Zahlung in Teile aufteilen (Teilrechnung).
  

Sie müssen außerdem zwei Merkmale berücksichtigen, die vollständig vom Zahlungsanbieter abhängen: Das Abonnement kann von Ihrer Anwendung gesteuert oder extern verwaltet werden.

• Ein intern verwaltetes Abonnement ist beispielsweise ein Abonnement mit Kreditkarten oder PayPal, wenn Sie nach der ersten Zahlung einen Token erhalten, mit dem Sie sich erneut beim Anbieter bewerben, ohne die Zahlungsdetails des Benutzers zu haben.
  
• Bei einem extern verwalteten Abonnement übernimmt der Zahlungsaggregator die vollständige Kontrolle über Ihre Abonnements und sendet Ihnen einfach Benachrichtigungen über deren aktuellen Status.
  

In der Abbildung sind die offensichtlichsten Bereiche, auf die normalerweise zuerst reagiert wird, violett hervorgehoben. Alle anderen werden erst viel später als Anhäufung von Fachwissen berücksichtigt. Dies wird weitgehend durch die fehlerhafte Anwendung iterativer Entwicklungsmethoden im Bereich der Abrechnung erleichtert.


Abbildung 2. Abrechnungsfälle, die hauptsächlich in Systemen implementiert sind

Eine solche schrittweise Implementierung kann zu unvorhersehbaren Konsequenzen führen. In einem der Projekte, an denen ich vor Badoo gearbeitet habe, wurde beispielsweise die Möglichkeit einer Rückerstattung nicht berücksichtigt. Infolgedessen wurden alle Rückgaben nicht durch Rückerstattungen, sondern durch Rückbuchungen erzielt, was sich negativ auf die Risikobewertung des Unternehmens auswirkte und zu Fehlern bei der Erfassung der Einkommensstatistik führte. Das Ignorieren der Vielzahl von Abrechnungsfällen kann zu entgangenen Gewinnen oder zur Anfälligkeit des Unternehmens für Benutzer führen, die sich betrogen fühlen.

Einerseits sollten Fehler in der Zahlungsabwicklung vor der Veröffentlichung gefunden werden, da sie zu den negativsten Konsequenzen führen können. Wenn dies nicht möglich war, ist es wichtig, schnell zu erkennen, dass der Fehler in die Release-Version der Anwendung gelangt ist, ihn zu beheben und vor allem, was viele Leute vergessen, Benutzer, die auf diesen Fehler stoßen, zu „beruhigen“.

Andererseits wird die Situation durch die Tatsache kompliziert, dass die Integration mit Zahlungsanbietern immer eine Interaktion mit der Black Box ist, die dem Testprozess viele Variablen hinzufügt.

Technische Probleme beim Abrechnungstest

Betrachten wir sie am Beispiel der Badoo-Integration in den App Store.

Abonnements im App Store gehören zur Klasse der extern verwalteten, dh sie werden vollständig vom Anbieter verwaltet, und unser System kann nur den aktuellen Status anfordern oder eine Benachrichtigung über seine Änderung erhalten.

Wir haben uns speziell für diese Integration entschieden, da sie die komplexeste ist und die unterschiedlichsten Fälle enthält, die bei der Integration des Dienstes in andere Zahlungsanbieter auftreten können.

Zunächst wenden wir uns einem einmaligen Verbrauchskauf zu.


Abbildung 3. Der Vorgang der Ausführung einer einmaligen Verbrauchszahlung

In Schritt 1 fordert der Benutzer den Kauf des Dienstes an. Der Antrag entscheidet, dass die Zahlung erfolgen soll, und in Schritt 2 wird die Kontrolle an den Zahlungsanbieter (App Store) übertragen. Schritt 3: Dem Benutzer wird ein Formular zur Zahlung angezeigt. Schritt 4: Der Benutzer stellt Daten zur Zahlung bereit. Schritt 5: Der Anbieter schließt die Transaktion ab und meldet das Ergebnis an die Anwendung. Er sendet eine Quittung mit vollständigen Informationen zum Kauf (Datum, Service, Status usw.) zurück. Schritt 6: Der mit Benutzerdaten ergänzte Scheck wird zur Verarbeitung an den Server gesendet. Der Server verarbeitet die Prüfdaten und generiert im siebten Schritt eine Push-Benachrichtigung für die Anwendung. Im achten Schritt wird dem Benutzer die Benachrichtigung angezeigt.

Das Problem ist, dass die Schritte 3, 4 und 5 auf der Seite des Zahlungsanbieters ausgeführt werden, praktisch nicht von uns kontrolliert werden und verschiedene Variationen aufweisen können. Somit hat der Prozess tatsächlich keine lineare Struktur, wie in Abbildung 2 gezeigt, sondern eine verzweigte (siehe Abbildung 4), und jede Verzweigung muss von der Anwendung anders behandelt werden.


Abbildung 4. Verzweigen eines Diagramms für den einmaligen Zahlungsstatus

Der Kauf von Abonnements beginnt auf die gleiche Weise wie eine einmalige Zahlung, aber eine weitere Kontrolle des Prozesses ist ziemlich schwierig zu kontrollieren.


Abbildung 5. Extern verwaltete Abonnementstatus

Ich möchte Sie daran erinnern, dass das Apple-Abonnement, das wir als Beispiel betrachten, extern verwaltet wird. Dies bedeutet, dass der Benutzer es nach dem Kauf asynchron verwalten kann: Schließen, Ablaufdatum ändern, Rückerstattung beantragen. Wir sehen dies in Schritt 9. Da die Aktion außerhalb unseres Systems stattfindet, habe ich sie in der Abbildung mit einer gepunkteten Linie markiert.

In Schritt 10 kann der App Store den Abonnementstatus ändern: Erneuern, Schließen, Geben Sie die Kulanzfrist in das Fenster ein.

Damit wir herausfinden können, in welchem ​​Status sich das Abonnement befindet, gibt es Schritt 11, der für Aggregatoren wie den App Store und Google Wallet spezifisch ist. In diesem Schritt sendet das System ein Token, das als Quittung verwendet wird, die zu Beginn beim Kauf eines Abonnements oder nach seiner vorherigen Verlängerung eingeht.

Schritt 12 ist die Antwort des Anbieters. Wir erhalten einen Scheck mit dem aktuellen Status des Abonnements. Das Ergebnis in diesem Schritt hängt von den asynchronen Schritten 9 und 10 ab.

Im Herbst 2018 hat Apple for all einen Mechanismus für Server-zu-Server-Benachrichtigungen implementiert, mit dem Sie über Änderungen benachrichtigen können, die bei einem Abonnement aufgetreten sind. Der Empfang einer solchen Benachrichtigung wird in Schritt 13 gezeigt. Für die meisten anderen Anbieter ist der Server-zu-Server-Benachrichtigungsmechanismus der einzige, sodass argumentiert werden kann, dass das Apple-Beispiel die gesamte Vielfalt der Fälle abdeckt. Bei anderen Anbietern können Sie in Schritt 13 die Schritte 11 und 12 vom Schema ausschließen.

In Schritt 14 generiert der Server eine Antwort für die Anwendung, um den Status des Abonnements zu ändern.

So haben wir ein vollständiges Diagramm der Zustände erhalten, die übergeben werden müssen, um bezahlte Dienste zu überprüfen.


Abbildung 6. Der vollständige Prozess zum Ändern des Zahlungsstatus (am Beispiel eines extern verwalteten Abonnements)

Die Teile, die wir in unserem System nicht steuern, sind orange gefärbt und für uns schwarze Kästchen.

Abrechnungsprüfverfahren

Das technische Hauptproblem beim Testen von kostenpflichtigen Diensten ist das Vorhandensein von „Black Boxes“, über deren Status wir nur sehr wenig Kontrolle haben. Dies definiert eine Reihe von Methoden, die die gesamte Vielfalt der Fälle abdecken können.

Es gibt nicht viele dieser Methoden, und wir haben sie in drei Kategorien unterteilt: reale Zahlungen, Sandboxen und Beseitigung externer Abhängigkeiten von den "Black Boxes".

Echte Zahlungen

Reale Zahlungen als Testmethode sind insofern gut, als sie eine klare Vorstellung vom Integrationszustand vermitteln. Ein Fehler bei der tatsächlichen Zahlung ist ein bedingungsloser Beweis für einen Fehler.

Ansonsten sind echte Zahlungen schlecht. Erstens ist es teuer: Es ist offensichtlich, dass Sie echtes Geld ausgeben müssen, um eine echte Zahlung zu leisten. Sie irren sich, wenn Sie der Meinung sind, dass am Ende der gesamte Betrag an das Unternehmen zurückgegeben wird: Erstens erheben die Anbieter für jede Transaktion eine Gebühr, deren Größe, wie oben beschrieben, von der Risikobewertung der Organisation abhängt und 40% (und sogar mehr) erreichen kann. ;; Zweitens können Sie beim Testen von Zahlungen in anderen Ländern aufgrund der Währungsspanne Geld verlieren - der Differenz zwischen den Kauf- und Verkaufskursen der Währung (Sie tätigen den Kauf zum Fremdwährungskurs der Bank, und die Rendite erfolgt zum Kaufkurs).

Darüber hinaus kann diese Methode sehr lange dauern, da Sie auf das Ende der Verlängerungsfrist für das Abonnement und den Ablauf der Nachfrist warten müssen. Dies können Monate sein.

Sandkästen

Sandkästen sind wunderschön. Dies ist in der Tat die gleiche Funktionalität, die uns ein Zahlungsanbieter im Falle einer echten Zahlung bietet, ohne jedoch echtes Geld auszugeben. Es wird vom Anbieter vollständig unterstützt, was bedeutet, dass die Integration in die Sandbox kostengünstig ist.

Das Problem der Dauer des Testens im Laufe der Zeit wird in der Regel mit verschiedenen Tricks gelöst. Beispielsweise verwendet die App Store-Sandbox die folgende Konvertierung zum Ablauf des Abonnements.

Tabelle 1. Das Verhältnis der Gültigkeitsdauer eines echten Abonnements und eines Abonnements in der Sandbox von Apple

Die Standardabonnements für die Google Wallet-Sandbox sind in Tabelle 2 aufgeführt und können in der Verkäuferkonsole konfiguriert werden.

Tabelle 2. Festlegen der Dauer eines Abonnements in der Google Sandbox

Im Gegensatz zur Apple-Sandbox können Sie auch die Testversion, die Kulanzfrist usw. in der Google-Sandbox anhand des Verhältnisses aus Tabelle 3 überprüfen.

Tabelle 3. Gültigkeit zusätzlicher Abonnementfunktionen in der Google Sandbox

Das Schließen eines Abonnements kann auch auf verschiedene Arten implementiert werden: In der Sandbox des App Store erfolgt das Schließen nach der fünften Verlängerung und in Google Wallet über die Konsole des Verkäufers oder auf dem Gerät aus dem Play Store.

Das Problem bei Sandboxen ist, dass Anbieter eine andere Einstellung zu ihrer Qualität haben. Unsere Erfahrung zeigt, dass von den mehr als 70 in Badoo integrierten Zahlungsanbietern nur zwei Sandboxen über volle Funktionalität und stabilen Betrieb verfügen. Dies sind die Sandkästen von Adyen und PayPal. Andere Anbieter haben entweder stabile, aber hinsichtlich der Funktionalität abgeschnittene Sandboxen (wie Google Wallet) oder instabile und stark abgeschnittene Funktionen (wie App Store und Fortumo). Und es gibt Anbieter, die keine Sandbox haben und überhaupt nicht haben werden.


Abbildung 7. Klassifizierung von Sandkästen nach Stabilität und Funktionalität

Externe Abhängigkeiten entfernen

Wenn wir Sie davon überzeugt haben, dass das Testen mit realen Zahlungen teuer und ineffizient ist und Zahlungsanbieter keine Sandboxen mit der richtigen Qualität bereitstellen, müssen wir uns verschiedenen Möglichkeiten zuwenden, um externe Abhängigkeiten zu beseitigen. Es gibt nur drei davon: Moki, Fakes und Stubs.

Moki bei der Abrechnung ist die Bildung der Reaktionen Ihres Systems auf Anfragen mit vorgegebenen Parametern ohne einen echten Anruf beim Zahlungsanbieter (siehe Abb. 8). Beispielsweise wird eine Anforderung an einen SMS-Zahlungsanbieter unter der Nummer + 7111-111-11-11 abgefangen, wenn eine Anforderung an den Anbieter gesendet wird, und eine Systemantwort in Form einer erfolgreichen Zahlung generiert. Die Anforderung an die Nummer + 7111-111-11-12 wird ebenfalls abgefangen, führt jedoch zu einer Reaktion auf einen Fehler mit dem Code "Es ist nicht genügend Geld vorhanden, um die Transaktion abzuschließen."


Abbildung 8. Mock-Diagramm

Fälschungen bei der Abrechnung sind Fälschungen von Benachrichtigungen (als ob sie von einem echten Anbieter stammen) (siehe Abb. 9). Die Integration mit jedem Anbieter impliziert eine begrenzte Anzahl von Systemreaktionen auf eine begrenzte Anzahl von Arten von Benachrichtigungen oder Zurücksetzungen. ( ), .


9.

— (. . 10), .


10.

, , . (, , ) . , , , , .

. 3, 4, 5 : , . - : , — , — . « ».


11. ( App Store)

, (, ). — , . . , , , . , . , .

. , ? :

• — ?
  
• end-to-end — : - ?
  
• — : , .
  

.


4.

. . . , . : , .

. , , Apple Google, . ( ). end-to-end : . , , .

, , — . . . : .

, , .

, . .

: . , , — .

, : — , , ; — : .


12.

, , , , .

, 12, Badoo.

. . QA- . , . , - , , . , .

: .

, , — . , Apple . . , . : - .

— , . -, . -, , -, , .

— : , Apple . 1 — , .

. , . , - .

, ( ).

Schlussfolgerungen

1. , .
   
2. ( ) . , .
   
3. « » , . - — . , : , — , — .
   
4. , , , , , . , .
   

, iOS-, .

! !