開発プロセス全体を通して統合をテストする必要があります。開発段階でテストするには、「ライセンス テスター」と 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 分 |
| お試し価格期間 | 定期購入のテスト期間と同じ |
| 猶予期間（3 日間と 7 日間の両方） | 5 分 |
| アカウントの凍結 | 10 分 |
| 一時停止（1 か月） | 5 分 |
| 一時停止（2 か月） | 10 分 |
| 一時停止（3 か月） | 休憩しましょう |
更新の加速
また、Play Billing Lab とライセンス テスターを使用して、次の手順でテスト定期購入の更新期間を短縮することもできます。
- [ダッシュボード] の [定期購入の設定] カードで [管理] をクリックします。
- テストする有効な定期購入を選択します。
- [今すぐ更新] をクリックします。
[今すぐ更新] ボタンをクリックすると、テスト サブスクリプションがすぐに更新されます。
次の点にご注意ください。
- 前倒し更新機能を利用する前にテスト定期購入を承認する必要があります。承認しない場合、定期購入は解約されます。
- 更新プロセスの実行には数秒かかることがあります。
- 料金改定が有効になっている場合、[今すぐ更新] ボタンは使用できません。
- 定期購入の更新中は、定期購入の料金変更機能をご利用いただけません。
トライアル特典
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 Billing Lab を使用せずに、どの地域でも購入フローをテストすることもできます。テストする手順は次のとおりです。
- 新しい Gmail アカウントを作成します。アカウントはどの国でも作成できます。
- 必要に応じて、そのユーザーをライセンス テスターとして設定します。
- テストする国に VPN 接続します。
- 購入フローを起動します。
Google Play ストアのデータとキャッシュを削除してから、ほかにテストする国でステップ 3 と 4 を繰り返すことができます。新しい国に切り替えた後、以前の国に関するデータを削除するために、Google Play ストアのデータを消去する必要があります。
購入をテストするこれらの方法のどちらでも、実際にテストする人がいる場所に関係なく、あらゆる地域で購入できるかどうか、およびユーザー エクスペリエンスをテストできます。