開発プロセス全体を通して統合をテストする必要があります。開発フェーズでテストするには、ライセンス テスターと 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 は Play ストアからダウンロードしてインストールできます。
Play Billing Lab を使用すると、テストで次のことができます。
- Play Billing Lab 内から [Play の国] を変更し、その設定をテストに適用します。これにより、テスターが物理的にテストする場所に関係なく、さまざまな国/地域でカスタムのユーザー エクスペリエンスをテストできます。
- 同じアカウントで繰り返し試用特典またはお試し特典をテストする
- 他のアクティブな定期購入者に影響を与えることなく、定期購入価格の変更をテストする
1 回限りのアイテムをテストする
消費可能アイテムをテストする
消費可能アイテムをテストするときは、次のようなさまざまな状況でテストすることをおすすめします。
- ユーザーがアイテムを受け取った購入。ライセンス テスターの場合は、「テスト支払い方法 - 常に承認」を使用できます。
- 支払い方法に請求できず、ユーザーがアイテムを受け取れない購入。ライセンス テスターの場合は、「テスト支払い方法 - 常に不承認」を使用できます。
- アイテムを複数回購入できるようにする。
また、購入が、購入の処理の説明のとおりに、適切に承認されることを確認する必要もあります。ライセンス テスターからの購入の場合、アプリが購入を承認しないと、3 分後に払い戻され、キャンセルに関するメールが届きます。Google Play Console の [注文] タブで、3 分後に払い戻しが行われたかどうかを確認することもできます。
消費不可アイテムをテストする
消費不可アイテムは、消費可能アイテムと同じようにテストする必要がありますが、アプリ内でアイテムを再度購入できないことを確認する必要があります。2 つのタイプの購入を処理するロジックはそれぞれ異なるため、消費不可アイテムと消費可能アイテムの両方について、購入の承認を確認してください（該当する場合）。
保留中の購入をテストする
保留中の購入をテストする必要があります。保留中の購入は、購入ステータスが PURCHASED になり、アイテムが付与されるべきである状況です。ライセンスを持つテストユーザーは、2 つのテスト機器を利用できます。それらのテスト機器では、遅延処理されるお支払い方法（数分が経過すると支払いが自動的に完了またはキャンセルされる）をテストできます。
図 2 に示すように、遅延お支払い方法「スロー テストカード、数分後に不承認」を使用して購入します。アプリを再起動し、購入が付与されていないことを確認します。
図 3. 不承認となったスロー テストカードを使用して購入をテスト。 図 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 試用特典のテスト機能では、ライセンス テスターは [無料試用またはお試し特典をテストする] チェックボックスをオンにして変更を適用することで、無料試用またはお試し特典を何度でもテストして使用できます。これにより、新規定期購読者限定のトライアル特典をテストするために、複数のアカウントを作成する必要がなくなります。
価格の変更
また、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 分 |
テストケース
[表示 / 非表示] をクリックして次のセクションを展開し、定期購入の統合の確認に使用するテストシナリオを表示してください。
プロモーション コードをテストする
Google Play Console を使用すると、独自のテスト用のコードを作成できます。プロモーション コードは、1 つのアプリで管理対象アイテムすべてにわたり、四半期ごとに 500 個しか作成できないことに留意してください。
次のプロモーション コードの利用シナリオをテストする必要があります。
- アプリ内で表示された購入ダイアログにプロモーション コードが入力されたとき。
- Google Play ストア アプリ内でプロモーション コードが利用されたとき。
- 左側のナビゲーションの [コードを利用] ボタンを使用して https://play.google.com/store でプロモーション コードが利用されたとき。
上記のシナリオでは、できるだけ多くの方法でコードの利用をテストする必要があります。少なくとも以下のテストを行うことをおすすめします。
- アプリがインストールされる前の利用。
- アプリがフォアグラウンドで実行されているときの利用。このテストでは、Google Play ストア アプリを使用してテストする別のデバイスが必要です。アプリのさまざまな画面から利用のテストを行ってください。
- アプリと Google Play ストア アプリの両方が同時に表示されるマルチウィンドウ モードでの利用。
各テストで、アイテムが正しく検出され、ユーザーに通知されることを確認します。
さまざまな地域で購入エクスペリエンスをテストする
Play Billing Lab とライセンス テスターを利用すると、任意の地域において、その国での実際のお支払い方法を必要とせずに、購入フローをテストできます。テストする手順は次のとおりです。
- アプリの課金ユーザーをライセンス テスターとして登録します。
- 同じユーザーで Play Billing Lab にログインします。
- 目的の国を選択し、Play 請求サービスのラボで変更を適用します。
- テスト対象のアプリで購入フローを起動します。
この方法で購入をテストすることで、実際にテストする人がいる場所に関係なく、あらゆる地域で購入できるかどうか、およびユーザー エクスペリエンスをテストできます。