Google は、黒人コミュニティに対する人種平等の促進に取り組んでいます。取り組みを見る

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 ストアに表示されます(アプリがインストールされているが、最新バージョンではない場合は、アプリの更新を求めるメッセージが表示されます)アプリがインストールされていないデバイスで、次のシーケンスをテストします。

  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 への公開を行ってください。