ステップ 6: エンドツーエンド テスト

エンドツーエンドのテストは、サンドボックス テストとソフトローンチ済み本番環境テストの 2 段階で行われます。

  1. サンドボックス テスト: サンドボックス フロントエンドを使用して、サンドボックスの在庫に対して一連のテストケースを実行します。サンドボックスの在庫への URL は、 [在庫] > [在庫] でアクセスできます。[公開中（サンドボックス内）] の販売者を見つけて、右端の列のリンク（利用可能な場合）をクリックするか、行をクリックして [RwG - E2E] リンクをクリックします。
  2. ソフトローンチされた本番環境でのテスト: サンドボックス テストが完了したら、Google の担当者に連絡してください。アカウントは「ソフトローンチ」状態になります。この時点で、本番環境の広告枠は予約可能になりますが、Google プロパティのエンドユーザーには外部から検出されなくなります。ソフトローンチされた広告枠には、 [広告枠] > [広告枠] でアクセスできます。[準備完了] の販売者を見つけて、右端の列のリンク（利用可能な場合）をクリックするか、行をクリックして [RwG - E2E] リンクをクリックします。この在庫へのアクセス方法と、これらの URL に関する特別な注意事項について詳しくは、こちらをご覧ください。サンドボックス環境で行ったのと同様の一連のテストケースを実行してください。

テストケース

以下のエンドツーエンドのテストは、サンドボックス テストとソフトローンチ済み本番環境テストの両方のテストの一部として実施します。

  • アクション センターで予約を行い、予約がシステムに正しく表示されることを確認します。
  • 確認メールが送信されていること、表示されている時間と予約が正しいことを確認します。
  • Actions Center で予約をキャンセルし、システムで正しくキャンセルされていることを確認します。
  • アクション センターで別の予約を行い、Booking Notification API を使ってシステムからキャンセルをトリガーします。
  • システムから特定のスロットを削除し、BatchAvailabilityLookupResponse と在庫のリアルタイム更新（該当する場合）によって Actions Center で正しく削除されているかどうかを確認します。注: RTU の遅延は 5 分未満です。
  • アクション センターから予約を変更し、変更した予約がシステムに正しく表示されることを確認します。
  • さまざまなスロットをクリックして、BatchAvailabilityLookup エラーが発生しないことを確認します。

デバッグ

空き状況スロットに関連する問題をデバッグする場合は、 パートナー ポータルの空き状況ビューアを使ってスロットの変更履歴を確認します。

リリースの準備

リリースの準備を整えるため、リリース準備アンケートに記入してください。このフォームを送信すると、リリースの準備が整ったことが Google に通知されます。

また、パートナー ポータルの [設定> 連絡先情報] タブで、すべての必須項目を入力してください。リリース前に連絡先情報フォームへのご入力が必要となります。

リリース前の準備として、以下の最終チェックリストを確認してください。

  • フィードのアップロードが毎日行われている。
  • 予約サーバーのエラー率が 5% 未満である。
  • リアルタイム更新のエラー率が 5% 未満である。
  • ユーザーのデータが安全に送信されている。
  • バックエンドからの第三者の予約リクエストがない。
  • 空き状況チェッカーが（できれば週末に）実行されてから 3 日以上経過しておらず、エラー発生率が 5% 未満である。

これらの手順が完了したら、Actions Center の担当者に連絡してリリース日を設定します。

前へ
ステップ 5: リアルタイム API 更新を実装する
次へ
ステップ 7: リリースとモニタリング