テスト完了（B2B）

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

ローンチ前に、環境に応じて必要なテストをすべて完了しておく必要があります。

品質保証は、お客様に影響が及ぶ前に問題を特定するうえで重要です。また、プロジェクトの性質によっては、Auth0 との統合の一環として考慮すべき品質保証テストには、さまざまな種類があります。

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

Auth0 の Universal Login と関連する UI ウィジェット (Lock など) は、ユーザビリティとアクセシビリティのベストプラクティスに従ってすでに設計・構築されており、幅広い ブラウザーとデバイス に対して、テスト済みのそのまま利用できるサポートを提供しています。国際化 (I18N) のサポートも標準で提供されており、カスタムの多言語対応やローカリゼーション (L10N) 向けに設計された組み込みの拡張機能も備えています。

機能要件が満たされ、予期しない事象が正しく処理されることを確認するために、アプリケーションと Auth0 間の統合をテストするためのガイダンスと、個々の拡張機能モジュール (Rules、Hooks、Custom Database スクリプトなど) の単体テストに関するガイダンスが提供されています。また、セキュリティ脆弱性の परीक्षणに役立つ Auth0 のペネトレーションテストポリシーに関するガイダンスに加え、予期しない負荷がかかった場合でもアプリケーションが適切に動作することを確認するため、モック テストを 負荷テストポリシー とあわせてどのように活用できるかについてのガイダンスも提供されています。

​

単体テスト

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

​

統合テスト

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

• Rules で変数を使用する場合は、値を設定する方法を参照してください
• Hooks で変数を使用する場合は、エディターでシークレットを設定する方法を参照してください
• Actions で変数を使用する場合は、Flows と Triggers の詳細を参照してください
• Custom DB Scripts で変数を使用する場合は、設定パラメーターを参照してください

​

ベストプラクティス

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

​

テスト自動化

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

​

モックテスト

Auth0 の負荷テストポリシーを踏まえつつ負荷テストを実施する方法として、Auth0 のお客様の間では Auth0 のエンドポイントをモック化することが一般的です。これは、テストを制限せずに、アプリケーションが想定どおりのインターフェイスで動作することを確認するための有効な手法であり、MockServer、JSON Server、あるいは Postman などのツールを活用できます。

​

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

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

​

負荷テスト (任意)

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

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

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

​

プロジェクト計画ガイド

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

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