Google Play Billing Library 統合をテストする

開発プロセス全体を通して統合をテストする必要があります。テスト 場合は、Google Cloud のインフラストラクチャを活用することをおすすめします。 ライセンス テスターPlay Billing Lab: 説明されたシナリオを実行する 説明します。

ライセンス テスター

ライセンス テスターを設定するには、以下をご覧ください。 アプリ ライセンスを使用してアプリ内課金をテストする

ライセンス テスターには、次のような利点があります。

  • 通常、Google Play Billing Library は、未署名で Google Play にアップロードされていないアプリに対してはブロックされます。ライセンス テスターはこのチェックを回避できます。つまり、デバッグ署名を持つデバッグビルドを使用しているアプリであっても、新しいバージョンのアプリをアップロードすることなく、テスト用にアプリをサイドローディングできます。ただし、パッケージ名は、Google Play 用に構成されたアプリのパッケージ名と一致する必要があります。また、Google アカウントは、Google Play Console アカウントのライセンス テスターでなければなりません。
  • ライセンス テスターは、購入に対して実際の課金が行われないテスト用支払い方法を利用できます。テスト用支払い方法は、支払いが承認されないなどの特定の状況のシミュレートにも使用します。購入フロー内に表示されるテスト用支払い方法を図 1 に示します。
  • ライセンス テスターは、定期購入の機能を迅速にテストすることができます。
ライセンス テスターはテスト用支払い方法を使用できる
図 1. ライセンス テスターはテスト用支払い方法を使用できる

テスト購入プロセスに関する追加情報:

  • テスト購入では、実際の購入と同じアプリ購入フローを使用します。
  • テスト購入では、税金は計算されません。
  • Google Play の購入ダイアログの中央に、テスト購入であることを示す通知が表示されます。

購入を行っているアカウントは、購入のダイアログを展開することで確認できます。次の点にご注意ください。

  • テスト アカウントは、テスターの Android デバイス上に存在する必要があります。
  • デバイスに複数のアカウントがある場合、アプリをダウンロードしたアカウントで購入が行われます。
  • いずれのアカウントでもアプリをダウンロードしていない場合は、最初のアカウントで購入が行われます。

アプリを配信する前に、Google Play テストトラックを利用して、その他の検証を行うことができます。たとえば、テストトラックを利用して、QA チームに新しいリリースを評価してもらうこともできます。

テストトラックを使用すると、ユーザーは Google Play からアプリをインストールして、未公開のアプリのバージョンをテストできます。ユーザーは、Google Play 内のどの支払い方法を使用しても、実際の購入を行うことができます。

テストトラックを使用して Google Play Billing Library 統合をテストするには、次の手順を実施します。

  1. テストトラックにアプリを公開します。テストトラックにアプリを公開した後、テスターがアプリを利用できるまでに数時間かかることがあります。
  2. 各テスターはアプリのテストにオプトインする必要があります。テスト用オプトイン URL には、テスター向けの注意事項とオプトイン確認のリンクが表示されます。

Android 1.6 以上を搭載するハードウェア デバイスであれば、統合をテストできます。ただし、Google Play アプリの最新バージョンがデバイスにインストールされている必要があります。Android 向けアプリの開発に使用するデバイスのセットアップ方法については、ハードウェア デバイスを使用するをご覧ください。

Play Billing Lab

Play Billing Lab は、Android でアプリの負荷を Google Play の課金システムとの統合。Kubernetes では、 デベロッパーが課金機能をテストし、 自信を持ってリリースできますGoogle Cloud SDK をダウンロードして Play Billing Lab の Google Play ストア:

Play Billing Lab のテストでは、次のことができます。

で確認できます。
Play 請求サービス ラボのダッシュボード
図 2.Play 請求サービス ラボのダッシュボード。
で確認できます。

1 回限りのアイテムをテストする

消費可能アイテムをテストする

消費可能アイテムをテストするときは、次のようなさまざまな状況でテストすることをおすすめします。

  • ユーザーがアイテムを受け取った購入。ライセンス テスターの場合は、「テスト支払い方法 - 常に承認」を使用できます。
  • 支払い方法に請求できず、ユーザーがアイテムを受け取れない購入。ライセンス テスターの場合は、「テスト支払い方法 - 常に不承認」を使用できます。
  • アイテムを複数回購入できるようにする。

また、購入が、購入の処理の説明のとおりに、適切に承認されることを確認する必要もあります。ライセンス テスターからの購入の場合、アプリが購入を承認しないと、3 分後に払い戻され、キャンセルに関するメールが届きます。Google Play Console の [注文] タブで、3 分後に払い戻しが行われたかどうかを確認することもできます。

消費不可アイテムをテストする

消費不可アイテムは、消費可能アイテムと同じようにテストする必要がありますが、アプリ内でアイテムを再度購入できないことを確認する必要があります。2 つのタイプの購入を処理するロジックはそれぞれ異なるため、消費不可アイテムと消費可能アイテムの両方について、購入の承認を確認してください(該当する場合)。

保留中の購入をテストする

保留中の購入をテストする必要があります。保留中の購入は、購入ステータスが PURCHASED になり、アイテムが付与されるべきである状況です。ライセンスを持つテストユーザーは、2 つのテスト機器を利用できます。それらのテスト機器では、遅延処理されるお支払い方法(数分が経過すると支払いが自動的に完了またはキャンセルされる)をテストできます。

  1. 図 2 に示すように、遅延お支払い方法「スロー テストカード、数分後に不承認」を使用して購入します。アプリを再起動し、購入が付与されていないことを確認します。

    不承認となったスロー テストカードを使用して購入をテストする
    図 3. 不承認となったスロー テストカードを使用して購入をテスト。

  2. 図 3 に示すように、遅延お支払い方法「スロー テストカード、数分後に承認」を使用して購入を行います。数分待ち、購入が許可されたことを確認します。

    承認されたスローテスト カードで購入をテストする
    図 4. 承認されたスローテスト カードで購入をテストします。

詳細については、保留中の取引の処理をご覧ください。

定期購入固有の機能をテストする

1 回限りのアイテムと定期購入の購入フローは似ていますが、定期購入の場合は、更新の承認や不承認などのシナリオが追加されます。更新をテストするには、図 1 に示すように、ライセンス テスターが利用できる「テスト支払い方法 - 常に承認」と「テスト支払い方法 - 常に不承認」を使用できます。2 つの支払い方法を使用することで、定期購入の購入後のシナリオをテストします。

1 回限りのアイテムと同じように、購入が購入の処理の説明のとおりに適切に承認されることを確認する必要もあります。ライセンス テスターからの購入の場合、アプリが購入を承認しないと、3 分後に払い戻され、キャンセルに関するメールが届きます。Google Play Console の [注文] タブで、3 分後に払い戻しが行われたかどうかを確認することもできます。

更新期間

テスト用の定期購入は、実際の定期購入よりも迅速に更新されます。 テスト用の定期購入では、更新は最大 6 回まで可能です(無料は含まれません)。 試用期間とお試し期間があります

テスト用定期購入の更新時間を下記の表に示します。表内の更新時間はおおよその値です。実際の時間は多少異なる可能性があります。この相違を補正するには、定期購入の有効期限ごとに API を呼び出して現在のステータスを確認してください。

本番環境用の定期購入の期間 テスト用の定期購入の更新
1 週間 5 分
1 か月 5 分
3 か月 10 分
6 か月 15 分
1 年 30 分

無料試用など、時間ベースの定期購入機能も、テスト用定期購入の場合は期間が短くなっています。時間ベースの定期購入機能のテスト期間を次の表に示します。

機能 テスト期間
購入の承認 5 分
無料試用 3 分
お試し価格期間 定期購入のテスト期間と同じ
猶予期間(3 日間と 7 日間の両方) 5 分
アカウントの凍結 10 分
一時停止(1 か月) 5 分
一時停止(2 か月) 10 分
一時停止(3 か月) 15 分

トライアル特典

Play Billing Lab のトライアル特典テスト機能を使用すると、 ライセンス テスターは、無料トライアルまたはお試し特典をテストして使用できます。 [無料試用またはお試し特典をテストする] チェックボックスをオンにして、 変更を適用しますこれにより、複数のサーバー VM を 新しい定期購入者のみが利用できるトライアル特典をテストする。

トライアル特典を試す
図 5. トライアル特典をテストする。

価格の変更

Play Billing Lab とライセンス テスターを使用してテストすることもできます。 定期購入の価格変更に 次の手順に沿って、他のアクティブなサブスクライバーに影響を及ぼします。

  1. ダッシュボードの [定期購入の設定] カードで [管理] をクリックします。
  2. テストする有効な定期購入を選択します。
  3. 新しい価格を入力します。
  4. テストの要件に応じて、[ユーザー オプトアウト] チェックボックスをオンまたはオフにします。
  5. [適用] をクリックします。
で確認できます。
定期購入の価格変更をテストする
図 6.定期購入の価格変更をテストする。

変更を適用すると、次の開始日から価格が更新されます。 テスターのみの更新が必要です。他の有効な定期購入者への影響はありません。 テスト サブスクリプションには、すべてのライセンス テスターのルールが適用されます。テスターは 価格変更によって引き起こされる下流のプロセス( 価格変更通知。

テスト期間を計画する際は、次の点に注意してください。

  • ライセンス テスターは更新期間が短いため、 コンソールで行った価格の移行は、ライセンス テスターに登録されません。宛先 デベロッパーが価格変更通知とメールをテストできるようにし、 価格変更のトリガー後 1 時間以上が経過してから請求を延期すること。
  • 値下げの場合は通知期間がありません。ユーザーへの通知 コホートの移行直後に値下げする。この点はテストでも変更ありません。
  • 値上げの場合のテスト通知回数は、以下のとおり実際の値上げと同じ方法で計算されます。
    • 最初の請求は、必須の通知期間経過後の最初の請求日に行われます。
    • 通知回数は、最初の請求日から遡って計算されます。
    • 最後の通知は、請求対象期間に関係なく、常に請求の 1 分前に送信されます。

次の表に、実際の請求対象期間でのテスト請求とテスト通知の期間を示します。

実際の基本プランの請求対象期間 テスト請求対象期間 テスト通知期間(30 日前の通知でオプトインおよびオプトアウトする地域) テスト通知期間(60 日前の通知でオプトアウトする地域)
1 週間 5 分 5 分 10 分
1 か月 5 分 5 分 10 分
3 か月 10 分 3 分 6 分
6 か月 15 分 2 分 4 分
1 年 30 分 3 分 6 分

テストケース

[表示 / 非表示] をクリックして次のセクションを展開し、定期購入の統合の確認に使用するテストシナリオを表示してください。

保留中のトランザクションをテストする

保留中の取引が正しく処理され、利用資格が 購入ステータスが PURCHASED になると、それに応じて更新されます。ライセンス テスター 遅延支払いのために 2 つのテスト手段を利用できます。 お支払いは数分後に自動的に完了またはキャンセルされます。

  1. 図 2 に示すように、遅延お支払い方法「スロー テストカード、数分後に不承認」を使用して購入します。アプリを再起動し、購入が付与されていないことを確認します。

    不承認となったスロー テストカードを使用して購入をテストする
    図 2. 不承認となったスロー テストカードを使用して購入をテスト。

  2. 図 3 に示すように、遅延お支払い方法「スロー テストカード、数分後に承認」を使用して購入を行います。数分待ち、購入が許可されたことを確認します。

    承認されたスローテスト カードで購入をテストする
    図 3. 承認されたスローテスト カードで購入をテストします。

プロモーション コードをテストする

Google Play Console を使用すると、独自のテスト用のコードを作成できます。プロモーション コードは、1 つのアプリで管理対象アイテムすべてにわたり、四半期ごとに 500 個しか作成できないことに留意してください。

次のプロモーション コードの利用シナリオをテストする必要があります。

  • アプリ内で表示された購入ダイアログにプロモーション コードが入力されたとき。
  • Google Play ストア アプリ内でプロモーション コードが利用されたとき。
  • 左側のナビゲーションの [コードを利用] ボタンを使用して https://play.google.com/store でプロモーション コードが利用されたとき。

上記のシナリオでは、できるだけ多くの方法でコードの利用をテストする必要があります。少なくとも以下のテストを行うことをおすすめします。

  • アプリがインストールされる前の利用。
  • アプリがフォアグラウンドで実行されているときの利用。このテストでは、Google Play ストア アプリを使用してテストする別のデバイスが必要です。アプリのさまざまな画面から利用のテストを行ってください。
  • アプリと Google Play ストア アプリの両方が同時に表示されるマルチウィンドウ モードでの利用。

各テストで、アイテムが正しく検出され、ユーザーに通知されることを確認します。

さまざまな地域で購入エクスペリエンスをテストする

Play Billing Lab の有無にかかわらず、購入エクスペリエンスをテストできます。

テストに使用する方法

Play Billing Lab Android アプリを使用すると、 購入フローを実行できますただし、 Play Billing Lab を使用するには、ライセンス テスターである必要があります。こちらの 次の手順でテストします

  1. アプリの請求ユーザーをライセンス テスターとして登録します。
  2. 同じユーザーで Play Billing Lab アプリにログインします。
  3. 希望する国を選択し、Play Billing Lab で変更を適用します。
  4. テスト中のアプリで購入フローを開始します。
で確認できます。
さまざまな地域で購入エクスペリエンスをテストする
図 7.複数の地域で購入エクスペリエンスをテストする。

テストなしでテストする

また、使用せずに任意の地域で購入フローをテストすることもできます。 Play Billing Labテストする手順は次のとおりです。

  1. 新しい Gmail アカウントを作成します。アカウントはどの国でも作成できます。
  2. 必要に応じて、ユーザーをライセンス テスターとして設定することもできます。
  3. テストする国に VPN 接続します。
  4. 購入フローを起動します。

Google Play ストアのデータとキャッシュを削除してから、手順 3 と 4 を必要に応じて繰り返します。 選択します新しい国に切り替えた後は、以下が必要になります。 Google Play ストアの [データを消去] をクリックすると、 国によって異なります。

どちらの購入方法でも、地域別の商品の利用資格と 物理的なテストを行う場所に関係なく、あらゆる地域のユーザー エクスペリエンスを維持できます。