テスト完了 (B2C)

B2C IAM 実装のローンチに向けたテスト準備。

ローンチ前に、お使いの環境に該当するすべてのテストを完了しておく必要があります。

Quality Assurance は、お客様に影響が及ぶ前に問題を特定するうえで重要です。また、プロジェクトの内容によっては、Auth0 との統合の一環として検討すべき品質保証テストには、いくつか異なる種類があります。

• アプリケーションは、障害のある方を含め、誰にとっても理解しやすく使いやすいものになっていますか？
• アプリケーションは、さまざまなブラウザーやデバイスで動作する必要がありますか？
• アプリケーションは、多国籍または国際的な環境で動作する必要がありますか？
• 想定外の本番負荷がかかった場合、アプリケーションはどのような動作をしますか？
• アプリケーションをセキュリティ上の脆弱性からどのように保護しますか？

Auth0 Universal Login および関連する UI ウィジェット (たとえば Lock) は、すでにユーザビリティとアクセシビリティのベストプラクティスに従って設計・構築されており、多数の ブラウザーおよびデバイス を標準でサポートしています。さらに、internationalization  (I18N) のサポートも標準で提供されており、カスタムの多言語対応やローカライズ (L10N) に対応するための拡張性も組み込まれています。

機能要件が満たされ、想定外の事象にも正しく対応できることを確認するために、アプリケーションと Auth0 の間の 統合 をテストするためのガイダンスと、個々の拡張モジュール (たとえば Rules、 Hooks、および Custom Database scripts) を対象とした 単体テスト のガイダンスが提供されています。また、セキュリティ脆弱性のテストに役立つよう、Auth0 の ペネトレーションテストポリシー に関するガイダンスも提供されています。さらに、想定外の負荷がかかった場合でもアプリケーションが適切に動作することを確認できるよう、当社の 負荷テストポリシー とあわせて モック テストをどのように活用できるかについても案内しています。

​

単体テスト

単体テストの目的は、コードの個々の単位をテストすることです。Auth0 内で Rules、Hooks、または Custom DB スクリプトとしてカスタムコードを作成する場合は、コードをテストするために Mocha などのテストフレームワークの使用を検討してください。Auth0 を特に効果的に活用している企業では、Auth0 テナントの設定や関連資産を自動的にデプロイする前に、これらの単体テストを実行することが有用だと分かっています。

​

統合テスト

SDLC support のアーキテクチャガイダンスで説明されているように、開発、テスト、本番用にそれぞれ別のテナントを設定することを推奨します。Auth0 では、カスタム extensibility 内から利用できる変数を設定できます。これらは、Auth0 テナント用の環境変数のようなものと考えることができます。開発、テスト、本番の各環境間でコードを移行するたびに変わる参照先をハードコードするのではなく、テナントで設定した変数名をカスタム extensibility コードから参照できます。これにより、コードは実行時にテナント固有の値が設定された変数を参照できるため、同じカスタムコードを変更せずに異なるテナントでも動作させやすくなります。

• Rules で変数を使用する場合は、値の設定方法を参照してください
• Hooks で変数を使用する場合は、エディタで secrets を設定する方法を参照してください
• Actions で変数を使用する場合は、Explore Flows and Triggers を参照してください
• Custom DB Scripts で変数を使用する場合は、設定パラメーターを参照してください

​

ベストプラクティス

テナント固有の値だけでなく、カスタムコード内に公開すべきでない機密性の高いシークレットを保持するためにも、変数を使用することを推奨します。カスタムコードを GitHub にデプロイしている場合、テナント固有の変数を使用することで、GitHub リポジトリを通じて機密値が露出するのを防げます。

​

テスト自動化

デプロイ自動化とテスト自動化を組み込むことで、ビルドプロセス全体を自動化できます。これにより、設定やカスタムコードの新しいバージョンを Auth0 にデプロイし、自動テストを実行できます。テストで問題が見つかった場合は、デプロイ自動化機能を使って、最後に正常に動作していたバージョンに戻すこともできます。詳細については、デプロイ自動化ガイダンスを参照してください。

​

モックテスト

Auth0 の 負荷テストポリシー と負荷テストを実施したいというニーズの兼ね合いから、Auth0 の顧客の間では Auth0 のエンドポイントをモック化するのが一般的です。これは、テストに制約をかけることなく、想定しているインターフェースでアプリケーションが正しく動作することを確認するうえで有効な方法であり、MockServer、JSON Server、さらには Postman などのツールを活用できます。

​

ペネトレーションテスト (任意)

ペネトレーションテストを実施する予定がある場合は、Auth0 のペネトレーションテストポリシーを確認し、それに従ってください。テストが悪意のあるアクティビティと誤認されて停止されないよう、事前に Auth0 へ通知する必要があります。

​

負荷テスト (任意)

負荷テストを実施する場合は、Auth0 の負荷テストポリシーを確認し、これに従ってください。負荷テストを行う際は、事前に Auth0 へ通知する必要があります。負荷テストを計画する際には、Auth0 のAPI レート制限についても把握しておく必要があります。

負荷テストを実施するには、Auth0 の負荷テストポリシーに記載されているとおり、事前に Auth0 の承認を得る必要があります。申請の審査に必要なリードタイムを必ず確認し、審査とテスト実施の両方に十分な時間を確保してください。負荷テストの申請が承認された場合は、以下のガイドラインに従うことで、エラーや不正確なテスト結果を避けやすくなります。

• アプリケーションのテスト実行時に HTTP トレースを取得し、アプリケーションまたは予定しているテストで必要となるすべての呼び出しを特定してください。そのうえで、本番環境で実際に発生する動作を適切に再現できるよう、それらがテストに含まれていることを確認してください。
• Auth0 API のレート制限を考慮してテストを設計してください。
• Auth0 内のカスタムコード (Actions、Rules、Hooks、カスタムデータベーススクリプト、カスタム OAuth 接続) を使用すると、Auth0 のカスタムコードサンドボックスが呼び出されるため、パフォーマンス面でより大きなコストがかかる可能性があります。Rules は、テストに不可欠でない限り無効にしてください。無効にすると、有効な場合よりもスループットが高くなります。
• 本番環境で想定される全体の負荷と、各エンドポイントへの呼び出し割合を見積もり、それに応じて性能テストを構成し、現実的な結果が得られるようにしてください。エンドポイントごとに性能コストは異なります。実態を反映したテストを設計しないと、誤解を招く結果になります。
• 先行する呼び出しの結果に依存する呼び出しは、前提となる呼び出しやレスポンスが完了したことを確認せずに実行しないでください。単に遅延を組み込むだけでは不十分な場合があります。
• 十分なエラーハンドリングを必ず実装してください。テスト中の問題でよくある原因の 1 つは、カスタムコード (Actions、Rules、Hooks、カスタムデータベーススクリプト、カスタム OAuth 接続スクリプト) 内の未処理例外によるエラーです。
• 負荷テストは、低いレベルから開始して段階的に負荷を上げ、各レベルでデータを収集するように作成してください。そうすることで、より有用な結果が得られます。高いレベルから始めてすぐに失敗すると、システムがどこまで耐えられるかについて得られる情報は少なくなります。
• 性能テストは、テスト対象のコードやテストハーネス/設定を調整しながら、複数回実行する必要があるのが一般的です。複数回の反復に十分な時間を確保できるよう、早めにテストを開始してください。
• 独自のメールプロバイダーアカウントを使用し、十分なメール送信クォータを事前に確保するよう手配してください。そうしないと、メールプロバイダーによってレート制限される可能性があります。メール送信を使用しない場合は無効にしてください。
• すべてのソーシャル接続では、Auth0 の開発用キーではなく、必ずご自身のアカウント認証情報を使用してください。Auth0 dashboard で、Connections -> Social -> {name of connection} に移動すると、接続にご自身のソーシャルプロバイダーのアカウント認証情報を追加する方法を確認できます。注: 一部のソーシャルプロバイダーでは負荷テストが許可されていません。各プロバイダーのポリシーを確認してください
• レート制限を回避し、実際の負荷をより正確に再現するために、テストでは同じユーザーに対するリクエストばかりではなく、異なるユーザーに対するリクエストを送信する必要があります。1 人または少数のユーザーしか使用しない場合、キャッシュによって実効負荷が下がり、現実的な結果が得られない可能性があります。
• テストについて合意した条件と Auth0 の負荷テストポリシーの範囲内に必ず留まってください。Auth0 は、合意した条件の範囲を超える、または予定されたテスト時間枠を超えて実施される性能/負荷テストを終了させる権利を留保します。

​

プロジェクト計画ガイド

推奨する戦略の詳細を確認できるよう、ダウンロードして参照できるPDF形式の計画ガイドをご用意しています。

B2C IAM プロジェクト計画ガイド