開発プロセス全体を通して統合をテストする必要があります。開発段階でテストするには、ライセンス テスターと Play Billing Lab を活用して、このセクションで説明するシナリオを実行することをおすすめします。
ライセンス テスター
ライセンス テスターを設定するには、アプリ ライセンスを使用したアプリ内課金のテストをご覧ください。
ライセンス テスターには、次のような利点があります。
- 通常、Google Play Billing Library は、未署名で Google Play にアップロードされていないアプリに対してはブロックされます。ライセンス テスターはこのチェックを回避できます。つまり、デバッグ署名を持つデバッグビルドを使用しているアプリであっても、新しいバージョンのアプリをアップロードすることなく、テスト用にアプリをサイドローディングできます。ただし、パッケージ名は、Google Play 用に構成されたアプリのパッケージ名と一致する必要があります。また、Google アカウントは、Google Play Console アカウントのライセンス テスターでなければなりません。
- ライセンス テスターは、購入に対して実際の課金が行われないテスト用支払い方法を利用できます。テスト用支払い方法は、支払いが承認されないなどの特定の状況のシミュレートにも使用します。購入フロー内に表示されるテスト用支払い方法を図 1 に示します。
- ライセンス テスターは、定期購入の機能を迅速にテストすることができます。
テスト購入プロセスに関する追加情報:
- テスト購入では、実際の購入と同じアプリ購入フローを使用します。
- テスト購入では、税金は計算されません。
- Google Play の購入ダイアログの中央に、テスト購入であることを示す通知が表示されます。
購入を行っているアカウントは、購入のダイアログを展開することで確認できます。次の点にご注意ください。
- テスト アカウントは、テスターの Android デバイス上に存在する必要があります。
- デバイスに複数のアカウントがある場合、アプリをダウンロードしたアカウントで購入が行われます。
- いずれのアカウントでもアプリをダウンロードしていない場合は、最初のアカウントで購入が行われます。
アプリを配信する前に、Google Play テストトラックを利用して、その他の検証を行うことができます。たとえば、テストトラックを利用して、QA チームに新しいリリースを評価してもらうこともできます。
テストトラックを使用すると、ユーザーは Google Play からアプリをインストールして、未公開のアプリのバージョンをテストできます。ユーザーは、Google Play 内のどの支払い方法を使用しても、実際の購入を行うことができます。
テストトラックを使用して Google Play Billing Library 統合をテストするには、次の手順を実施します。
- テストトラックにアプリを公開します。テストトラックにアプリを公開した後、テスターがアプリを利用できるまでに数時間かかることがあります。
- 各テスターはアプリのテストにオプトインする必要があります。テスト用オプトイン URL には、テスター向けの注意事項とオプトイン確認のリンクが表示されます。
Android 1.6 以上を搭載するハードウェア デバイスであれば、統合をテストできます。ただし、Google Play アプリの最新バージョンがデバイスにインストールされている必要があります。Android 向けアプリの開発に使用するデバイスのセットアップ方法については、ハードウェア デバイスを使用するをご覧ください。
Play Billing Lab
Play Billing Lab は、デベロッパーが Google Play の課金システムとの統合をテストできる Android アプリです。これにより、デベロッパーは簡単かつ便利な方法で課金機能をテストし、より迅速に統合して、自信を持ってリリースできます。Play Billing Lab は、Google Play ストアからダウンロードしてインストールできます。
Play Billing Lab のテストでは、次のことができます。
- Play Billing Lab 内から [Play の国] を変更し、設定をテストに適用します。これにより、テスターが物理的にテストしている場所に関係なく、さまざまな国/地域でカスタム ユーザー エクスペリエンスをテストできます。
- 同じアカウントで繰り返しトライアルやお試し特典をテストする
- 他の有効な定期購入者に影響を与えずに定期購入価格の変更をテストする
- 定期購入の更新を早めることで、テストを迅速化できます。
- 実際のお支払い方法でテストし、特定の購入フローのリスクシグナルを回避
1 回限りのアイテムをテストする
消費可能アイテムをテストする
消費可能アイテムをテストする場合は、次のようなさまざまな状況をテストします。
- ユーザーがアイテムを受け取った購入。ライセンス テスターの場合は、「テスト支払い方法 - 常に承認」を使用できます。
- 支払い方法に請求できず、ユーザーがアイテムを受け取れない購入。ライセンス テスターの場合は、「テスト支払い方法 - 常に不承認」を使用できます。
- アイテムを複数回購入できるようにする。
購入が購入の処理の説明のとおりに適切に承認されていることを確認します。ライセンス テスターからの購入の場合、アプリが購入を承認しないと、3 分後に払い戻され、キャンセルに関するメールが届きます。Google Play Console の [注文] タブで、3 分後に払い戻しが行われたかどうかを確認することもできます。
消費不可アイテムをテストする
消費不可アイテムは、消費可能アイテムと同じようにテストする必要がありますが、アプリ内でアイテムを再度購入できないことを確認する必要があります。2 つのタイプの購入を処理するロジックはそれぞれ異なるため、消費不可アイテムと消費可能アイテムの両方について、購入の承認を確認してください（該当する場合）。
保留中の購入をテストする
購入ステータスが PURCHASED になったときにアイテムが付与されるべき保留中の購入をテストします。ライセンスを持つテストユーザーは、2 つのテスト機器を利用できます。それらのテスト機器では、遅延処理されるお支払い方法（数分が経過すると支払いが自動的に完了またはキャンセルされる）をテストできます。
遅延しているお支払い方法で購入します。図 3 のとおり、テストに時間がかかったカードが数分後に不承認になります。アプリを再起動し、購入が付与されていないことを確認します。
図 3. 不承認となったスロー テストカードを使用して購入をテスト。 遅延のお支払い方法を使用して購入を行います（図 4 のとおり、スローテストカードが数分後に承認されます）。数分待ち、購入が許可されたことを確認します。
図 4. 承認されたスローテスト カードで購入をテストします。
詳細については、保留中の取引の処理をご覧ください。
定期購入固有の機能をテストする
1 回限りのアイテムと定期購入の購入フローは似ていますが、定期購入の場合は、更新の承認や不承認などのシナリオが追加されます。更新をテストするには、[テストカード、常に承認] と [テストカード、常に不承認] を使用します。これらの支払い方法は、ライセンス テスターが使用できます（図 1 を参照）。2 つの支払い方法を使用することで、定期購入の購入後のシナリオをテストします。
1 回限りのアイテムと同様に、購入が購入の処理の説明のとおりに適切に承認されていることを確認します。ライセンス テスターからの購入の場合、アプリが購入を承認しないと、3 分後に払い戻しが行われ、キャンセルに関するメールが届きます。Google Play Console の [注文] タブで、3 分後に払い戻しが行われたかどうかを確認することもできます。
更新期間
テスト用定期購入は、実際の定期購入よりも迅速に更新され、無料試用やお試し期間を除いて更新できる回数は最大 6 回です。
テスト用定期購入の更新時間を下記の表に示します。表内の更新時間はおおよその値です。実際の時間は多少異なる可能性があります。この相違を補正するには、定期購入の有効期限ごとに API を呼び出して現在のステータスを確認してください。
| 本番環境用の定期購入の期間 | テスト用の定期購入の更新 |
| 1 週間 | 5 分 |
| 1 か月 | 5 分 |
| 3 か月 | 10 分 |
| 6 か月 | 15 分 |
| 1 年 | 30 分 |
無料試用などの時間ベースの定期購入機能も、テストのため短縮されています。時間ベースの定期購入機能のテスト期間を次の表に示します。
| 機能 | テスト期間 |
| 購入の承認 | 5 分 |
| 無料試用 | 3 分 |
| お試し価格期間 | 定期購入のテスト期間と同じ |
| 猶予期間 | 5 分 |
| アカウントの凍結 | 10 分 |
| 一時停止（1 か月） | 5 分 |
| 一時停止（2 か月） | 10 分 |
| 一時停止（3 か月） | 休憩しましょう |
更新の加速
Play Billing Lab とライセンス テスターを使用して、テスト用の定期購入の更新期間を早めることもできます。手順は次のとおりです。
- ダッシュボードの [定期購入の設定] カードで [管理] をクリックします。
- テストする有効な定期購入を選択します。
- [今すぐ更新] をクリックします。
[今すぐ更新] ボタンをクリックすると、テスト用の定期購入はその後すぐに更新されます。
次の点にご注意ください。
- テスト定期購入は、Accelerated Renewal 機能を使用する前に承認する必要があります。承認されない場合、定期購入は解約されます。
- 更新処理が完了するまでに数秒かかることがあります。
- 価格変更の適用中は、[今すぐ更新] ボタンは使用できません。
- 定期購入の更新中は、定期購入の価格変更機能は利用できません。
トライアル特典
Play Billing Lab のお試し特典テスト機能を使用すると、ライセンス テスターは、[無料試用またはお試し特典をテストする] チェックボックスをオンにして変更を適用することで、無料試用またはお試し特典を無制限にテストして使用できます。これにより、新規登録者のみが利用できるトライアル特典をテストするために複数のアカウントを作成する必要がなくなります。
価格の変更
Play Billing Lab とライセンス テスターを使用して、他の有効な定期購入者に影響を与えることなく、定期購入の価格変更をテストすることもできます。手順は次のとおりです。
- ダッシュボードの [定期購入の設定] カードで [管理] をクリックします。
- テストする有効な定期購入を選択します。
- 新しい価格を入力します。
- テストの要件に応じて、[ユーザー オプトアウト] チェックボックスをオンまたはオフにします。
- [適用] をクリックします。
変更を適用すると、次回の更新からテスターのみを対象に価格が更新されます。他のアクティブな購読者への影響はありません。 テスト サブスクリプションには、すべてのライセンス テスターのルールが適用されます。テスターは、価格変更の通知など、価格変更によってトリガーされたダウンストリーム プロセスについてアプリをテストできます。
テスト期間を計画する際は、次の点に注意してください。
- ライセンス テスターは更新期間が短いため、コンソールから価格の移行を行った場合は、ライセンス テスターに登録されない可能性があります。価格変更の通知とメールを確実にテストできるようにするには、価格変更をトリガーしてから少なくとも 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 つのテスト機器にアクセスして、支払いが遅延するお支払い方法を利用できます。支払いは自動的に完了するか、数分後に支払いがキャンセルされます。
遅延しているお支払い方法で購入を行います（図 8 のとおり、テストに時間がかかったカードが数分後に不承認になります）。アプリを再起動し、購入が付与されていないことを確認します。
図 8. 不承認となったスロー テストカードを使用して購入をテスト。 遅延のお支払い方法を使用して購入を行います（図 9 に示すように、スローテストカードが数分後に承認される）。数分待ち、購入が許可されたことを確認します。
図 9. 承認されたスローテスト カードで購入をテストします。
プロモーション コードをテストする
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 を使用するには、ライセンス テスターである必要があります。テストする手順は次のとおりです。
- アプリの請求ユーザーをライセンス テスターとして登録します。
- 同じユーザーで Play Billing Lab アプリにログインします。
- ご希望の国を選択し、Play Billing Lab で変更を適用します。
- テスト中のアプリで購入フローを開始します。
テストなしでテストする
Play 請求サービス ラボを使用せずに、任意の地域で購入フローをテストすることもできます。テストする手順は次のとおりです。
- 新しい Gmail アカウントを作成します。アカウントはどの国でも作成できます。
- 必要に応じて、ユーザーをライセンス テスターとして設定することもできます。
- テストする国に VPN 接続します。
- 購入フローを起動します。
Google Play ストアのデータとキャッシュを削除してから、テストする国で手順 3 と 4 を繰り返します。新しい国に切り替えた後に、以前の国に関連するデータを削除するには、Google Play ストアのデータを消去する必要があります。
どちらの購入方法でも、物理的にテストする場所に関係なく、地域の利用資格とユーザー エクスペリエンスを任意の地域でテストできます。
実際のお支払い方法を使用して購入エクスペリエンスをテストする
Play Billing Lab Android アプリを使用すると、実際のお支払い方法を使用して購入エクスペリエンスをテストできます。
実際のお支払い方法をテストする手順は次のとおりです。
- Google アカウント ユーザーをライセンス テスターとして登録します。
- 同じユーザーで Play Billing Lab アプリにログインします。
- Play Billing Lab アプリで実際のお支払い方法を有効にします。
- テスト中のアプリで、購入フローを再起動して開始します。