Google Play 請求サービスのテスト

Google Play 請求サービスの実装後は、アプリ内アイテムの購入をテストできます。このドキュメントでは以下の項目について説明します。

テストの準備をする

Google Play 請求サービスの実装に関するテストの準備をするには、次の手順を行います。

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

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

Google Play 請求サービスを実装するアプリの単独テストを行う

静的レスポンスを使用してテストする

Google Play 請求サービスでは、予約済みのアイテム ID と関連する静的レスポンスの組み合わせが提供されるため、それを使用して Google Play 請求サービスの実装をテストできます。このようなレスポンスを使用することで、アプリが主要な Google Play レスポンスを適切に処理できているか検証できます。テスターの参加前や、アプリの公開前であっても、静的レスポンスを使用して Google Play 請求サービスの実装をテストできます。

静的レスポンスを使用して実装をテストするには、予約済みアイテム ID を持つ特別なアイテムを使用して、Google Play 請求サービスをリクエストします。各予約済みアイテム ID は、それぞれ Google Play から固有の静的レスポンスを返します。予約済みアイテム ID を使用した Google Play 請求サービス リクエストの場合、送金処理は発生しません。また、この場合、支払い方法の指定はできません。

注: 静的レスポンスは定期購入のテストには使用できません。

アプリのアイテムリストに、予約済みアイテムを含める必要はありません。Google Play は、自動的に予約済みアイテム ID を認識します。また、予約済みアイテム ID を使用した静的レスポンス テストを実施する際、Google Play Console にアプリをアップロードする必要もありません。アプリをデバイスにインストールして、デバイスにログインし、予約済みアイテム ID を使用して Google Play 請求サービスをリクエストするだけです。

注: 以前は、公開前のドラフト版をアップロードしてアプリをテストできました。この機能は現在サポートされていません。代わりに、Google Play ストアにアップロードする前に、静的レスポンスを使用してアプリをテストすることができます。詳細については、静的レスポンスを使用してテストするをご覧ください。

Google Play 請求サービスの静的レスポンスをテストする際は、以下の 3 つの予約済みアイテム ID を利用できます。

  • android.test.purchased

    このアイテム ID を使用して Google Play 請求サービスをリクエストすると、Google Play は「アイテムが購入された」と見なしてレスポンスを返します。レスポンスには JSON 文字列が含まれており、疑似購入情報(例: 疑似オーダー ID)が格納されます。

  • android.test.canceled

    このアイテム ID を使用して Google Play 請求サービスをリクエストすると、Google Play は「購入がキャンセルされた」と見なしてレスポンスを返します。クレジット カードが無効の場合や、課金前にデベロッパーがユーザーのオーダーをキャンセルした場合など、オーダー プロセス内でエラーが発生したケースに相当します。

  • android.test.item_unavailable

    このアイテム ID を使用して Google Play 請求サービスをリクエストすると、Google Play は「購入対象のアイテムがアプリのアイテムリストに含まれていない」と見なしてレスポンスを返します。

予約済みアイテム ID を使用して Google Play 請求サービスをリクエストするには、通常どおり REQUEST_PURCHASE リクエストを作成します。ただし、アプリのアイテムリストにある実際のアイテム ID を使用する代わりに、予約済みアイテム ID を使用します。

予約済みアイテム ID を使用したアプリのテストは、次の手順で行います。

  1. 購入フローの中で 3 つの予約済みアイテム ID のいずれかを使用するようにアプリを編集します。アイテム ID を使用して購入する方法については、アプリ内アイテムの購入を有効にするをご覧ください。
  2. Android デバイスにアプリをインストールします。

    エミュレータを使用して Google Play 請求サービスをテストすることはできません。Google Play 請求サービスをテストするデバイス上にアプリをインストールする必要があります。

    デバイスにアプリをインストールする方法については、デバイス上で実行するをご覧ください。

  3. デベロッパー アカウントでデバイスにログインします。

    予約済みアイテム ID だけを使用してテストを実施する場合、テスト アカウントを使用する必要はありません。

  4. サポート対象バージョンの Google Play アプリ、または MyApps アプリがデバイス上で稼働していることを確認します。

    Android 3.0 を搭載しているデバイスの場合、Google Play 請求サービスを利用するには、バージョン 5.0.12 以降の MyApps アプリが必要です。それ以外のバージョンの Android の場合、Google Play 請求サービスを利用するには、バージョン 2.3.4 以降の Google Play アプリが必要です。Google Play アプリのバージョンをチェックするには、アプリを起動して [設定] メニューを開き、下にスクロールしてバージョン情報を表示します。

  5. アプリを実行し、予約済みアイテム ID を使用して購入を行います。onPurchasesUpdated() 内のコードが静的レスポンスを正しく処理しているか確認します。onPurchasesUpdated() の実装方法については、アプリ内アイテムの購入を有効にするをご覧ください。
  6. 他の予約済みアイテム ID を使用してテストを繰り返します。

: 予約済みアイテム ID を使用して Google Play 請求サービスをリクエストすると、通常の本番環境 Google Play システムがオーバーライドされます。予約済みアイテム ID に対して Google Play 請求サービスのリクエストを送信した場合、そのサービス品質は本番環境と異なる場合があります。

購入フロー全体をテストする

静的レスポンスのテストが完了し、アプリ内で署名検証が機能していることを確認したら、実際にアプリ内購入を行って Google Play 請求サービスの実装をテストします。実際のアプリ内購入のテストを行うことで、ユーザーが実際に行う Google Play 内での購入やアプリ内での購入手続きフローなど、Google Play 請求サービスのプロセス全体をテストすることができます。

注: クローズド テストトラックに公開すると、アプリの包括的なテストを実施できます。この場合、Google Play ストアにアプリを公開できますが、利用できるのはデベロッパーが指定したテスターに限られます。

実際のアプリ内購入プロセスを使用して Google Play 請求サービスの実装をテストするには、テスト アカウントを使用する必要があります。デフォルトでは、登録されている唯一のテスト アカウントは、デベロッパー アカウントに関連付けられています。Google Play Console を使用することで、追加のテスト アカウントを登録できます。これまでにテスト アカウントをセットアップしたことがない場合は、テスト アカウントをセットアップするをご覧ください。

テスト アカウントは、アイテムリスト内のアイテムを購入できますが、そのアイテムが公開されている場合に限られます。

実際の購入プロセスを使用して Google Play 請求サービスの実装をテストする手順は次のとおりです。

  1. Google Play Console 内で、クローズド テストトラックにアプリをアップロードします。

    注: 最初にアプリをアップロードした後は、アプリのデベロッパー版を Google Play Console にアップロードしなくても、ライセンス テスターはアプリから購入を行うことができます。これにより、デベロッパーは新しいバージョンを毎回アップロードすることなく、デバッグされた署名付きのビルドを使用して変更を加えることができます。

    注: 以前は、公開前のドラフト版をアップロードしてアプリをテストできました。この機能は現在サポートされていません。代わりに、クローズド テストトラックまたはオープン テストトラックに公開する必要があります。詳細については、ドラフト版アプリのサポート終了をご覧ください。

  2. Google Play Console 内で、アプリ内アイテムを作成します。詳細については、1 回限りのアイテムを作成する定期購入を作成するをご覧ください。
  3. Android デバイスにアプリをインストールします。エミュレータでは Google Play 請求サービスをテストできません。デバイスにアプリをインストールする方法については、デバイス上でアプリを実行するをご覧ください。
  4. サポート対象バージョンの Google Play アプリ、または MyApps アプリがデバイス上で稼働していることを確認します。Android 3.0 を搭載しているデバイスの場合、Google Play 請求サービスを利用するには、バージョン 5.0.12 以降の MyApps アプリが必要です。それ以外のバージョンの Android の場合、Google Play 請求サービスを利用するには、バージョン 2.3.4 以降の Google Play アプリが必要です。Google Play アプリのバージョンをチェックする方法については、Google Play をアップデートするをご覧ください。
  5. アプリ内で、アプリ内購入を行います。

注: デバイスのメイン アカウントを変更するには、出荷時の設定にリセットする必要があります。必ず最初にメイン アカウントでログインするようにしてください。

Google Play 請求サービスを実装するアプリのユーザーテストを行う

テスト アカウントを設定する

テスター アカウントをセットアップするには:

  1. Google Play Console を使用して、テスターに購入してもらうアプリ内アイテムをアップロードし、公開します。APK 自体を公開する前に、アプリ内アイテムをアップロードし、公開することができます。
  2. Developer Console を使用して、ライセンス テスター アカウントを作成します。
    1. [設定] > [アカウントの詳細] に移動します。
    2. [ライセンス テスト] の [テスト用のアクセス権がある Gmail アカウント] に、テスターのメールアドレスを追加します。
    3. 変更内容を保存します。15 分以内に、テスターがアプリ内アイテムの購入を開始できるようになります。

: テスト アカウントは、テスターの Android デバイス上に存在する必要があります。デバイスに複数のアカウントがある場合、アプリをダウンロードしたアカウントで購入を行うことになります。いずれのアカウントでもアプリをダウンロードしていない場合は、最初のアカウントで購入が行われます。ユーザーは、購入ダイアログを展開することで、購入に使用するアカウントを確定できます。

テスターにテスト購入を依頼する

テスト アカウントをセットアップしたら、テスト購入を行うようにユーザーに依頼します。テスト購入プロセスの概要は次のとおりです。

  • ユーザーは、通常のユーザーと同じアプリ購入フローを使用します。
  • ユーザーは、少なくとも 2 回購入を行う必要があります。1 回は「常に承認」の支払い方法で、もう 1 回は「常に不承認」の支払い方法で行います。2 つの支払い方法でテストすることにより、支払いが承認される場合と不承認になる場合の両方でアプリが正しく反応するか検証できます。購入フロー内に表示されるテスト用支払い方法を図 1 に示します。
    図 1: ライセンス テスター向けのテスト用支払い方法オプション
    ライセンス テスターが使用できる支払い方法は、この 2 つに限られます。いずれかの支払い方法を使用すると、購入フローがすぐに結果を返します。
  • テスト購入では、税金は計算されません。
  • ライセンス テスターの購入に対しては課金されません。
  • Google Play の購入ダイアログの中央に、テスト購入であることを示す通知が表示されます。

注: 1 つのアプリ内アイテムに対して複数のテスト購入を実行できるようにするには、各購入後に「消費済み」のマークをアイテムに付けます。マークを付けるには、consumeAsync() を呼び出します。

実際のアカウントでテストする

Google Play 請求サービスを使用したアプリの公開を準備する際は、Google Play のクローズド リリース オプションやオープン リリース オプションを活用することで、全ユーザーにアプリを配信する前に、実装の検証や読み込みテストを実施することができます。

クローズド テストグループやオープン テストグループを利用すると、ユーザーは、Google Play からアプリをインストールし、アプリ内アイテムをテストすることができます。ユーザーは、Google Play 内で通常の支払い方法を使用して、実際の購入を行うことができます。その結果、実際にユーザーのアカウントに課金されます。

注: 配信用のクローズド テストグループやオープン テストグループにテスト用ライセンス アカウントを含めた場合、そのアカウントのユーザーは、テスト購入だけを行うことができます。

1 回限りのアイテム固有の機能をテストする

アプリ内プロモーションをテストする

アプリがアプリ内プロモーションをサポートしている場合、以下のユースケースをテストします。

ユーザーがアプリ内でプロモーション コードを利用する

ユーザーがアプリの購入フローに沿ってプロモーション コードを利用した場合は、Google Play 請求サービス リクエストを行うの説明のとおり、システムはアクティビティの onActivityResult() メソッドを呼び出して、購入を処理します。ユーザーが代金を支払った場合でも、プロモーション コードを利用した場合でも、onActivityResult() が購入を正しく処理しているか検証します。

ユーザーが Google Play ストア内でプロモーション コードを利用する

ユーザーが Play ストア内でプロモーション コードを利用した場合、いくつかのワークフローが考えられます。各ワークフローをそれぞれ検証します。

アプリがインストールされていない場合

デバイスにインストールしていないアプリのプロモーション コードをユーザーが利用しようとした場合、Play ストアは、アプリをインストールするようユーザーに求めます(アプリがインストールされていても最新版ではない場合、Play ストアは、アプリをアップデートするようユーザーに求めます)。アプリがインストールされていないデバイスで、次のシーケンスをテストします。

  1. ユーザーが、Play ストア内でアプリのプロモーション コードを利用します。Play ストアが、アプリをインストールするようユーザーに求めます。
  2. ユーザーが、アプリをインストールして起動します。起動時にアプリが getPurchases() を呼び出し、ユーザーがプロモーション コードを使って行った購入を正しく検出しているか検証します。
アプリはインストールされているが、実行中ではない場合

デバイスにインストールされているアプリのプロモーション コードをユーザーが利用しようとした場合、Play ストアは、そのアプリに切り替えるようユーザーに求めます。アプリはインストール済みだが実行中ではないデバイスで、次のシーケンスをテストします。

  1. ユーザーが、Play ストア内でアプリのプロモーション コードを利用します。Play ストアが、アプリを切り替えるようユーザーに求めます。
  2. ユーザーが、対象のアプリを起動します。起動時にアプリが getPurchases() を呼び出し、ユーザーがプロモーション コードを使って行った購入を正しく検出しているか検証します。
アプリがインストールされていて、実行中の場合

デバイス上で現在実行中のアプリのプロモーション コードをユーザーが利用しようとした場合、Play ストアは、PURCHASES_UPDATED インテントを通じてアプリに通知します。次のシーケンスをテストします。

  1. ユーザーが、対象のアプリを起動します。PURCHASES_UPDATED インテントを受信できるようにアプリが正しく登録されているか検証します。
  2. ユーザーは、手動で、あるいはプロモーション コードを含む生成 URL を使用して、Play ストア アプリを起動し、対象アプリのプロモーション コードを利用します。Play ストアが、PURCHASES_UPDATED インテントを発行します。アプリの BroadcastReceiver.onReceive() コールバックがトリガーされて、インテントを処理しているか検証します。
  3. onReceive() メソッドが、getPurchases() を呼び出して、インテントに応答する必要があります。アプリがこのメソッドを呼び出し、ユーザーがプロモーション コードを使用して行った購入を正しく検出しているか検証します。
  4. ユーザーが、対象アプリに戻ります。購入したアイテムをユーザーが所持しているか検証します。

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

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

定期購入の更新をテストする

テスト用定期購入は、簡単にテストできるように通常よりも短時間で更新されます。テスト用定期購入の更新時間を下記の表に示します。

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

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

注: テスト用定期購入は、最大で 6 回更新できます。

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

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

更新頻度のテストシナリオ

更新頻度のテストシナリオを表示するには、[表示 / 非表示] をクリックしてください。各テストシナリオにおいて、どのような間隔で更新が行われるのかが示されています。

完了したテスト購入をキャンセルする

Google Play は、ユーザーごとに完了したテスト購入を蓄積しており、支払いプロセスには渡していません。

テスト購入は自動でキャンセルされないため、テスト購入を手動でキャンセルして、テストを続けたいケースもあるかもしれません。その場合、Play ストアでアプリのページを開きます。キャンセルしたいテスト購入が定期購入の場合、Purchases.subscriptions API の cancel() メソッドを使用することもできます。

重要: Purchases.subscriptions API の refund() メソッドと revoke() メソッドは、テスト購入に対応していません。

次の手順

Google Play 請求サービスの実装テストが完了すれば、Google Play でアプリを公開する準備は完了です。通常の手順で、準備署名Google Play への公開を行ってください。