QAから見た世界的な請求Badoo

こんにちは、Habr！ 4年以上にわたって、私はBadoo課金システムの手動および自動テストに携わってきました。 また、Badoo課金は世界で最も開発された（そして複雑な）ものの1つであり、それをテストすることは多くの場合、興味深く、並外れたタスクです。 今日、これらのシステムが非常に興味深く、強力である理由、長年にわたって学んだこと、および請求のテストが（ 非常に ）怖くない理由をお話したいと思います。 そして同時に、私はあなたと興味深い物語の別のバッチを共有します（ はい、私はこのビジネスが大好きです） 。 ほとんどのことは、特定のケースだけでなく、他の複雑な支払いシステムにも適用できます（ 正直なところ、支払いシステムだけでなく ）。



請求は何ですか？ これは、3億3千万人以上のユーザーが登録されているソーシャルネットワークの支払い処理システムです。 私たちは世界のすべての国で支払いを受け付け、30を超えるアクティブな支払い方法をサポートし（そして、それらの約100が常に実装されています）、1秒あたり約1500件のリクエストを処理します。 Billing Badooは、多数の異なるクライアント（異なるプラットフォーム、異なるアプリケーション）で動作する独立した専用サービスです。 テストを開発するのに十分な好奇心が強いですね。

テスト対象

それで、まず最初に、私たちが正確にテストしなければならないことを簡単に説明します。 すべてのクライアント（Web、モバイルアプリケーション、および一部のバックエンドサービス）は、APIを使用して課金と通信します。 課金自体は各データセンターの個別のクラスターに配置され、さまざまな支払いシステムと通信します（支払い要求の送信、要求の処理結果を伴う通知の受信など）。 クラスターには、顧客の要求と支払いシステムを処理するマシン、CLIスクリプトを起動するマシン（たとえば、期限切れのサブスクリプションサービスを更新するマシン）、銀行カード支払いとデータベースを処理する独自のサーバーが含まれます。







課金開発者は、いくつかのタイプのタスクを処理します。

• 新しい機能の開発 ：新しい有料サービス、プロモーションキャンペーン、加入者向けのさまざまな機能。
• 支払いサービスとの新しい統合の開発 （ より低いコミッションまたはより高いコンバージョンを持つ人を常に見つけることができます ）;
• 既存の統合の更新 （ 当社のパートナーも開発中です ）;
• バグの修正 （ 認めましょう-誰もが持っています！ ）;
• 技術的な負債を最適化して解決するタスク （ いつでもサービスを少し改善することができます ）;
• テクニカルサポートの問題を解決します （ さまざまな国のさまざまな支払いサービスに多数のサブスクリプションを作成し、不要なものをキャンセルする方法を混乱させる最もmostなユーザーを愛しています ）。

そして、これらすべての「良い」ことは、最終的に私たちの小さなチームをテストすることになります。 課金開発者から直接のタスクに加えて、他のチームが支払いに関係がある場合は、クライアントやモバイルアプリケーションサーバーの変更や新機能など、他のチームからもタスクを受け取ります。



正確に何をテストしていますか？ すべてを3つのカテゴリに分類できます。

• ユーザーインターフェイス ：さまざまなプラットフォーム、設定ウィンドウ、広告バナー、プロモーションウィンドウなどのすべての種類の支払いウィンドウ（ 「ウィザード」と呼びます ）。
• 「管理パネル」と設定ツール ：価格、プロモーションキャンペーン、実験、技術サポートツールの設定（テスト中も非常に積極的に使用しています）。
• バックエンドの請求 ：支払いの処理、サービスの提供のためのキュー、およびさまざまな遅延操作の実行（ 最も困難で「ジューシーな」部分 ）。

これらすべてについて順番に話そうと思います。

ユーザーインターフェース

したがって、ここで最も重要な部分は支払いウィザードです。 同じ機能（購入したいサービスの量とその方法に関する情報をユーザーから受け取る）を実行すると、ウィザードはプラットフォームごとに異なって見えます。 これは主にプラットフォームの機能に依存しますが、規制当局のさまざまな要件と、アプリケーションで実行される無数のA / Bテストにも依存します。



ここで何をテストできますか？ はい、すべての海！ 選択したサービスオプションに対して、各支払い方法が正しく表示されるはずです。 オプションのリスト自体は目的のリストに対応する必要があり、それぞれに請求設定で指定された価格が含まれている必要があります。価格と通貨の形式は、国で採用されている標準に準拠する必要があります（例： $ 6.49、125.00 MXNまたは17.64BYN） 。



各支払いウィンドウには、詳細な利用規約が必要です。 各プロモーションウィンドウには、必要なものすべてが含まれているか、条件の完全な説明とともに次のステップに進む必要があります（ ちなみに、これは忘れがちな最も一般的な問題の1つです ）。



このようなウィンドウでのユーザーアクションには、支払いの成功に関するエラーだけでなく、エラーに関する正しいメッセージも添付する必要があります（ユーザーがパートナー側で支払いをキャンセルしたときと、実際に間違った情報を入力したときを区別できる必要があります）。



このすべてに対して基本的なチェックのセットを作成し、それに限定できるように思われます。 あった！ 各国には、ビジネスを行うために遵守しなければならない独自の必須要件があります。 たとえば、ベルギーでSMSを使用して支払いを行う場合、短い支払い番号を黒い長方形の中に大きな白い数字で描画する必要があります（ 冗談ではありません ）。 フランスでは、サイトのすべてのページに一度に既存のサブスクリプションサービスからサブスクライブを解除するボタンが必要でしたが、サブスクライブ解除自体は確認ステップなしでワンクリックで実行する必要があります。 一部の国では、価格に税金が含まれていることを通知することが不可欠であり、他の一部の国では、サービスのコストと追加の税金を個別に示すことさえあります（ そしてそれらを合計する場所はありません ）。



支払い方法のこのような「動物園」を確認する方法は？ 最も正直なテストのために世界のすべての国に旅行することは失敗します（ そして、ブラジルで支払いをテストしたいですsob ）、また、既存のすべての支払いシステムでアカウントを作成します。 したがって、さまざまな「サンドボックス」に満足する必要があります。 一部のパートナーは、銀行カードアグリゲーターやPayPalなど、非常に便利な独自のサンドボックスを提供してくれます。 そのうちのいくつかはそれほど機能的ではありません。パートナーの1社にとっては、「支払い」ボタンが重ねられた通常の支払いウィンドウのスクリーンショットです 。



他の場合には、さまざまな回答や通知をエミュレートするサンドボックスを自分で構築する必要があります。 しかし、これでもどこでもうまくいくわけではなく、手で通知を収集し、コード内で何らかの置換を行い、httpsリクエストで自分に送信する必要があります。



モバイルアプリケーションのウィザードは、まったく別の頭痛の種です。 ここでは、ユーザーはさらに間接的に請求と通信します。 アプリケーションは、支払いシステム（AppleStoreやGoogleWalletなど）に要求を送信します。応答はモバイルアプリケーションサーバーに直ちに送信され、モバイルアプリケーションサーバーは情報を処理して新しい要求を請求クラスターに送信し、請求応答はこのようにすべて支払いシステムに戻ります。 ユーザーエクスペリエンスは、このチェーンのどこでも中断する可能性があります。 エラーの雲は、要求が請求に達せず、支払いが完了しなかったことを意味する場合がありますが、すべてがうまくいったことを意味する場合もありますが、モバイルアプリケーションサーバーは、予期したとおりの形式で支払いシステムに応答しませんでした。 混乱！



また、特にサブスクリプションをテストしようとする場合、AppleやGoogleにある不快なサンドボックスについてはここで話さないでください。



ところで、外部のパートナーと協力するという事実は、多くの問題をもたらします。 支払いウィンドウは長時間開いてテストの速度を低下させる可能性があり、最も一般的なバグ（ 自尊心のあるテスターとして、まず自分の開発者に起因するバグ） を含めることができます。 協力が必要なアクション（同じバグの修正、プロトコル拡張）も遅延することが多く、私たちに通知せずに独自に変更を加えることができます（ エラースケジュールの増加からのみ学習します ）。不完全なドキュメントまたは誤ったドキュメントですらあります。

管理者

課金の重要な要素は、ユーザーの目から完全に隠されています。 これにより、当社の管理者はサービスの価格と可用性を調整し、プロモーションキャンペーンを開始できます。また、テクニカルサポートワーカーはユーザーの問題の原因を特定し（ サービスを「無料」で取得しようとしていないことを確認します ）そしてそれらを解決する安全な方法。 さらに、これらのすべてのツールはテストに役立ちます（多くの場合、ユーザーインターフェースのアクションだけで、または非常に長い時間プレイすることは非常に困難です）。



直接的なパフォーマンスチェックに加えて、開発者と管理者が実装された機能を同じ方法で認識することを保証するために多くの時間を費やす必要があります（ 多くの場合、両者間の連絡を確立して相互理解を完了することしかできません ）。 すべての構成システムは、幅広い機能のために非常に複雑です（常に多数のA / B設計テスト、支払い方法、および販促キャンペーンがあります）。また、ほんのわずかな詳細であっても、システムの動作が予想とはまったく異なる場合があります。管理 私たちの責任は、開発者がタスクを正しく理解し、管理者が提供されたドキュメント（ある場合 ）を把握できるようにすることです。 そしてもちろん、コンフィギュレーターを変更するたびに、作業の結果を追跡し、誰もが本当にこれを実行したいかどうかを明確にすることは非常にクールです。



そして、ここで私たちが開発したツールの1つを自慢する必要があります（もちろんテスト済みです！）必要な銀行や口座にカード支払いをルーティングするために、名誉あるMerchant Spotlight Awardを獲得しました。

バックエンド

そして、ここから楽しみが始まります。 一般ユーザーの目に見えないもの; マネージャーが何も知りたくないこと 開発者の最も恐ろしい空想が具現化される場所-支払いの処理とサービスの提供の内部ロジック







あらゆる種類のことをテストするだけです。

• アフィリエイトシステムへのアピール ：サブスクリプションのステータスの確認（一部についてはサブスクリプションを管理できない場合があり、それらがまだアクティブであることのみを確認できます）、サブスクリプションの更新およびキャンセルのリクエストなど。
  
  
  
  
• パートナーからの通知の処理 ：各通知を正しく処理する必要があり（各パートナーには独自の形式とプロトコルがあります！）、ユーザー、サービス、および混乱しないようにすべての可能なパラメーターを決定します。 通知がまったく意味をなさない場合もあります：「 見て、まだユーザーからお金を差し引くことができませんでした ！」、時には矛盾している場合があります ：「 ユーザーが支払いをキャンセルしました:(いいえ、ここにお金が来ました！ 」;時々完全に無関係です：「 3年前にそのサブスクリプションを覚えていますか？今では、まだ有効期限が切れています！ 」-そして、すべての可能なケースに対して正しい「フロー」を考え出す必要があります。
  
  
  
  
• サービスの提供 ：問題が発生した場合にユーザーの順序を失わないように、サービスはキューを通じて提供されます。 何かがうまくいかなかった場合-イベントは延期され、どのような場合でもすべてのサービスがユーザーに配信されます。 これは「いずれにしても」テスト中に保証する必要があります。
  
  
  
  
• サブスクリプションの更新 ：ユーザーが特定のサービスにサブスクライブしている場合、時間通りにそれらを受け取る必要があります。 時間よりも早く（または遅く）「請求」するべきではありません。常に彼が申し込んだ金額から引き落とされるべきです。 さらに、さまざまな国でサブスクリプションを更新する時間を選択するためのさまざまなロジックがあります（これらは、実験または規制当局の要件のいずれかです）。 たとえば、営業時間中にのみユーザーを「魅了」する場所や、特定の曜日にのみユーザーを「魅了する」場所です。
  
  
  
  
• 利用可能なデータに応じた支払い ：自尊心のある支払いシステムと同様に、ユーザーは次回の支払いを高速化するために支払い方法の詳細を保存できます。 詳細が安全に保存されていることを確認する必要があります（たとえば、銀行カードの場合、PCI DSSに準拠する必要があります）。支払いが処理され、詳細が有効でなくなった場合（ユーザーのカードがブロックされるなど）にケースが正しく処理されます。
  
  
  
  
• などなど 。

サーバーコード内のさまざまなロジックの量は、単に無制限です。 新しいタスクはそれぞれ、「どのように機能するかを理解する=>どのように機能する必要があるかを理解する=>システムをこのように機能させる方法を理解する」というタイプの楽しいクエストに変わります。 これを達成する方法は何ですか？



まず、 コードを読む必要があります 。 ブラックボックスとして請求をテストすることはほとんど不可能です。システムの仕組みを知っているだけで、ここでテストできるケースを理解できます。 さらに、テストを成功させるために頻繁にコードを変更する必要があります：アグリゲーターへの呼び出しを削除し（存在しないテストサブスクリプションのステータスを要求しないようにする）、通知の署名検証を置き換えます（そのため、毎回生成する必要はありません）または「ハードコード」 A / Bテストでの特定のオプションの選択（望ましいグループに分類される多数のユーザーを登録しないようにするため）。 幸いなことに、これらのプロセスを簡素化するためのテストユーティリティを開発するために最善を尽くしています。



第二に、 非自明な方法で物事をテストすることを恐れてはいけません 。 インターフェースからケースを確実に再生できませんか？ 機能テストを書くことができます！ 「ペン」でテストベースに登り、必要なデータを入力できます！ パートナーから通知を手動で収集し、自分のアドレスに送信できます！ 主なものは、野生に登ることを恐れないことです。



第三に、 開発者はあなたの友人です。 共同の楽しいデバッグは、魅力的（ 常にではない ）で結集したチームです（ 開発者を絞殺したい場合を除く ）。 予期しない動作と一緒にすると、はるかに簡単になります。 そして、あなたはあなたの間違いを理解してタスクを正当化するか、実際の問題を見つけて開発者にそれを完成させるために戻ってもらい、すでに状況をある程度理解します（ または古い開発者が休暇に入った場合は新しい開発者に状況を整理します ）。

自動テスト

自動テストは非常にクールなものです。 実際、ここでのテストは、 テストしないよりもはるかに優れています 。 私たちと直接、すべての自動テストを4つのグループに分けることができます。

• 単体テスト ：開発者がタスクの作業中に作成します。 このプロセスでは、テストでカバーされるまで、タスクは解決されたとは見なされません。
• 統合テスト ：再現が難しい場所をチェックするために、テスト段階で開発者（および場合によってはテスター）によって作成されます。 単体テストのように、コードの一部を置換し続けますが、同時にはるかに広いエンティティのレイヤーで動作します。
• SeleniumとCalabashのシステムテスト ：ユーザーに見えるクライアントをテストします。 理想的には安定しておらず、十分に低速ではありませんが、他の部門のタスクによって引き起こされた問題を見つけることもできるため、非常に便利です。
• システムカールテスト ：かなり新しい方向。 数千の異なるケースでシステムの全体的なパフォーマンスをチェックします。世界中のすべての国で、すべての支払い方法で、すべてのサービス、すべてのオプションの支払いウィザードを取得します。 そのまま再テスト。

これらのテストはいつ実行されますか？ さまざまな組み合わせで、これは常に発生します。

• 開発者は、タスクで作業するときに手動でテストを実行します。
• タスクが「完了」ステータスに移行すると、自動的に起動されます。
• QAエンジニアは、テスト中にそれらを手動で実行します。
• ビルドの新しいバージョンをビルドするたびに起動されます。
• 最終的に、それらはプリプロダクションで常に定期的に実行されます。

もちろん、これらのすべての自動テストにはかなりの時間がかかるため、このプロセスを可能な限り最適化するよう常に努力しています。 統合テストと単体テスト（さらに最近ではcurlテスト）では、クラウドベースの「テストランチャー」を使用します（ 4分で73,000以上のテストが既に！ ）。 Seleniumテストには、SeleniumGridクラスターの「大規模ファーム」があります。 そして一般的に、テストの改善と最適化の作業は止まりません。

モニタリング

タスクに対するテスターの作業は、タスクが本番に送信された時点ですぐには停止しません。 戦闘環境での作業のストレスに耐えられるようにすることは、注意深い監視によってのみ可能です。 新しい予期しないエラーがログに表示されましたか （ はい、予想されるエラーが発生します、これは正常ですか？） 課金クラスターの負荷は増加しましたか？ ある国またはある支払い方法で利益が減少し始めていますか （ または、急激に増加しますが、これも通常奇妙です）。 Badooには、24時間体制ですべてのメトリックを手動および自動モードで監視する素晴らしい監視部門があります。 ただし、いずれにせよ、特定の異常の原因を独立して特定するためには、ある程度の時間が必要です。 したがって、QAエンジニアは（ 最後の ）バトルでタスクを慎重に実行する必要があります。



これらの目的のために、いくつかの異なるシステムを使用しますが、そのうち最も重要なものは3つです。

• RRDツール ：RRDには、エラーログとデバッグログ、膨大な数の基本的なメトリック（利益、支払いの数、レンダリングされたサービスの数、キューサイズ）のグラフが格納されます。
• Splunk ：楽しいシステムで、すべての請求イベントをリアルタイムで分析することで、さまざまな請求リクエストの数や時間などに関するさまざまなグラフを作成できます。
• 異常検出 ：メトリックの予期しない動作を自動的に報告する独自の異常検出システム。 最初の2つのシステムとは異なり、このシステムは完全自動モードで動作します。

請求チャートで異常と見なされるものは何ですか？ ポーランドでこのチャートを見てみましょう。 各ポイントは最終日の総利益を示し、チャートのスケールも1日です。









悪夢、ひどい利益の低下、すべての鐘を打たなければなりません！ しかし、それは何ですか？ その月のチャートを開きます...









なんてこった？ これが、ポーランドでのモバイルアグリゲーターの仕組みです。 すべてのサブスクリプションの更新は、火曜日などの特定の曜日にのみ行われます。 ユーザーが月曜日に1週間購読した場合、...彼は火曜日の「zacharjat」とまったく同じです！ これがポーランドのルールです。 そして、各ピークは、あるアグリゲーターの「大切な」曜日です。



さらに調べます。 AppleStoreの来月24日から1日までの週の利益の同様のグラフ：









怖がってる？ もちろん！ そのような秋、1日あたりの成長なし-明確な問題！ オフィスを真っ直ぐに駆け抜けて悲鳴を上げる間、一日が過ぎます。 そして、私たちは何を見ますか？









スケジュールは自然に回復しました！ 魔法？ 致命的な間違い？ 爬虫類プロット？ まったく、これはAppleのポリシーです。 サブスクリプションは、サブスクリプションが開始された月の同じ日に常に更新されます。 しかし、2月に30日または31日から登録を開始したユーザーはどうなりますか？1か月間無料で無料で座っていますか？ もちろんそうではありませんが、2月28日の「充電」です。 そして、それ以降、28の番号のみが請求を開始しました。 そのため、月末にはこれら2つのピークが下がり（2月の28日目と他のすべての「短い」月の30日目）、31日目にサブスクリプションは1か月以上更新されません。



ご覧のとおり、監視も賢明に必要です。 すでに述べたように、 テストすることはそれほど悪くはありませんが、過度の警戒心のために開発者からカフをキャッチすることもできます。

結論の代わりに

課金のテストは、面白くて楽しいものです。 そこには多くの異常なもの、落とし穴、裏通りがありますが、誰にも知られていませんが、ほぼすべてのタスクの解決策は本当の探求であり、それを完了すると絶対的な勝利を味わえます。 このテスト領域についてあまり語られていないのは残念です（ そして会議で、「そして、私たちは本番で課金をテストします」のようなことを繰り返し聞いています ）。 私の記事が、誰かが彼らの会社のテストプロセスを違った見方をし、おそらく、彼らの支払いシステムをもう少し厳しくテストすることに決めるのを助けることを願っています。 とにかく、低レベルのもの。 私を信じて、これは本当に退屈ではありません！



クディノフイリヤシニア QAエンジニア