> ## Documentation Index > Fetch the complete documentation index at: https://auth0.com/llms.txt > Use this file to discover all available pages before exploring further. # テスト完了（B2C） > B2C IAMの実装開始に向けたテストの準備。 実装開始前に、ご利用の環境に適用されるすべてのテストを完了してください。 品質保証は、重大な影響を受ける前に問題を特定するために重要です。プロジェクトの性質に応じて、異なる種類の品質保証テストから適したものを選び、Auth0統合の一環として実施することをご検討ください。 * アプリケーションは、障がいのある人にとっても理解しやすく、使いやすいですか。 * アプリケーションは、多種のブラウザーやデバイスで動作する必要がありますか。 * アプリケーションは、複数の国で、あるいは国際的な環境で動作する必要がありますか。 * 予期しない生産負荷が発生した場合、アプリケーションのパフォーマンスはどうなりますか。 * セキュリティー関連の脆弱性からアプリケーションをどのように保護しますか。 Auth0の[ユニバーサルログイン](/docs/ja-jp/authenticate/login/auth0-universal-login)および関連するUIウィジェット（[Lock](/docs/ja-jp/libraries/lock)など）は、使いやすさとアクセシビリティのベスト プラクティスに従ってすでに設計および構築されており、多くの[ブラウザーやデバイス](/docs/ja-jp/troubleshoot/customer-support/product-support-matrix)に対してそのまますぐに使えるテスト済みのサポートを提供しています。[国際化](/docs/ja-jp/customize/internationalization-and-localization)（I18N）のサポートも初めから組み込まれており、カスタムの多言語・ローカリゼーション（L10N）シナリオに対応できる拡張性を備えています。 機能的な要件が満たされ、予期しないイベントが正しく処理されるように、アプリケーションとAuth0の間の[統合](#integration-testing)をテストするためのガイダンスと、個々の拡張モジュール（[Rules](/docs/ja-jp/customize/rules/debug-rules)、[Hooks](/docs/ja-jp/customize/hooks/update-hooks)、カスタム データベースのスクリプトなど）の[ユニットテスト](#unit-testing)に関するガイダンスが提供されます。また、セキュリティの脆弱性をテストする際に役立つAuth0の[ペネトレーションテストポリシー](/docs/ja-jp/troubleshoot/customer-support/operational-policies/penetration-testing-policy)に関するガイダンスも提供されます。さらに、[負荷テストポリシー](/docs/ja-jp/troubleshoot/customer-support/operational-policies/load-testing-policy)と組み合わせて[モック](#mock-testing)テストを活用して、予期しない負荷の下でもアプリケーションが確実に動作するための情報も提供されます。 ## ユニットテスト ユニットテストの目的は、コードの個々のユニットをテストすることです。Auth0内でRules、Hooks、カスタムDBスクリプトの形式でカスタムコードを作成する場合は、テストフレームワーク（[Mocha](https://mochajs.org/)など）を使用してコードをテストすることを検討してください。Auth0を上手に活用している企業は、Auth0テナントの構成その他を[自動的にデプロイ](/docs/ja-jp/get-started/architecture-scenarios/business-to-consumer/deployment)する前にユニットテストを行うと効果的だと言います。 ## 統合テスト ベストプラクティスとして、開発・テスト・運用用に個別のテナントをセットアップすることをお勧めします（「[SDLCサポート](/docs/ja-jp/architecture-scenarios/b2c/architecture#sdlc-support)のアーキテクチャガイダンス」を参照）。Auth0を使用すると、カスタム[拡張性](/docs/ja-jp/customize/extensions)内から使用できる変数を構成できます。これらは、Auth0テナントの環境変数とみなすことができます。ハードコード化された参照は、開発・テスト・運用環境間で移動すると変わってしまうため、代わりに、テナントで構成され、カスタムの拡張コードによって参照される変数名を使用することができます。コードが変数を参照すれば、実行時にテナント固有の値が書き込まれるため、同じカスタムコードを異なるテナントで変更せずに使用できます。 * Rulesでの変数の使用については、[値の構成方法](/docs/ja-jp/customize/rules/configuration)を参照してください * Hooksでの変数の使用については、エディターで[シークレット](/docs/ja-jp/customize/hooks/hook-secrets)の構成方法を参照してください * Actionsでの変数の使用については、「フローとトリガーを見る」を参照してください * カスタムDBスクリプトでの変数の使用については、[構成パラメーター](/docs/ja-jp/connections/database/custom-db/create-db-connection#step-3-add-configuration-parameters)を参照してください ### ベストプラクティス テナント固有の値や、カスタムコードで公開すべきではないセンシティブな情報を含むには、変数を使用するのがおすすめです。カスタムコードがGitHubにデプロイされている場合、テナント固有の変数を使用すればGitHubリポジトリを通じたセンシティブな値の公開を避けられます。 ### テスト自動化 デプロイメントの自動化とテストの自動化を組み込めば、ビルドプロセス全体を自動化できます。これを利用して、新しいバージョンの構成やカスタムコードをAuth0に導入し、自動テストを実行することができます。テストでエラーが見つかった場合は、デプロイメントの自動化機能を使用して、動作していた最後のバージョンに戻すことができます。詳細については、提供されている[「デプロイメントの自動化に関するガイダンス」](/docs/ja-jp/get-started/architecture-scenarios/business-to-consumer/deployment)を参照してください。 ## モックテスト Auth0の[負荷テストポリシー](/docs/ja-jp/troubleshoot/customer-support/operational-policies/load-testing-policy)と負荷テストを行いたいという要望とのバランスを取るため、Auth0のエンドポイントをモックすることが慣行となっています。これは、テストを制約することなく、想定したインターフェイスでのアプリケーションの動作を確認できる有効な方法であり、補助として[MockServer](http://www.mock-server.com/)、[JSON Server](https://github.com/typicode/json-server)、[Postman](https://learning.getpostman.com/docs/postman/mock_servers/setting_up_mock/)といったツールを使用できます。 ## ペネトレーションテスト（任意） ペネトレーションテストを実行する場合は、Auth0の[ペネトレーションポリシー](/docs/ja-jp/troubleshoot/customer-support/operational-policies/penetration-testing-policy)に留意し、それに従ってください。ペネトレーションテストを実行する際は、テストが悪意あるアクティビティと混同され、シャットダウンを引き起こさないように、Auth0への事前通知が必要です。 ## 負荷テスト（任意） 負荷テストを実行する場合は、Auth0の[負荷テストポリシー](/docs/ja-jp/troubleshoot/customer-support/operational-policies/load-testing-policy)に留意し、それに従ってください。負荷テストではAuth0への事前通知が必要です。負荷テストを計画する際は、Auth0の[APIレート制限](/docs/ja-jp/troubleshoot/customer-support/operational-policies/rate-limit-policy)にも注意を払う必要があります。 負荷テストはAuth0負荷テストポリシーで説明されている通り、Auth0からの事前承認が必要です。リクエストをしてからレビューにかかる時間に留意して、レビューとテスト実行のための時間を十分に確保するようにしてください。負荷テストのリクエストが承認されたら、エラーや不完全なテスト結果を回避するため、以下のガイダンスを参考にしてください。 * 実際の運用時に発生するすべての事項がテストされるよう、ご使用のアプリケーションのテスト時にHTTPトレースを実行して、アプリケーションまたは意図されたテストが行う必要のあるすべての呼び出しを特定します。 * テストを設計する際はAPIレート制限に留意します。 * Auth0のカスタムコード（Actions、Rules、 Hooks、カスタムデータベースのスクリプト、カスタムOAuth接続）を使うと、Auth0カスタムサンドボックスが呼び出されて性能が落ちる可能性があります。テストに不可欠でない限り、Rulesはオフにしてください。Rulesがオフだと、オンにされている場合に比べてスループットが改善します。 * 現実的なテスト結果をられるよう、運用環境で予想される全体の負荷と各エンドポイントへの呼び出し比率を推定し、それに基づいてパフォーマンステストを構成します。エンドポイントが異なればパフォーマンスコストも異なります。実際の環境を代表するテストを設計しないと、誤解を生じる結果になりかねません。 * 前提条件となっている呼び出しや応答が完了したことを確認せずに、以前の呼び出し結果に依存する呼び出しを行わないようにします。遅延させるだけでは十分でない場合があります。 * 必ず適切なエラー処理を実行します。テスト時に頻繁に発生する問題は、カスタムコード（Actions、Rules、 Hooks、カスタムデータベースのスクリプト、カスタムOAuth接続スクリプト）の例外処理が行われないことに起因するカスタムコードエラーです。 * 負荷テストは、最初低レベルで開始し、徐々にレベルを上げて各レベルでデータをキャプチャし、最も有益な結果が得られるように書いてください。高いレベルで開始してすぐに機能が停止しても、システムがどれだけ耐えられるかについての情報はそれほど得られません。 * 通常、パフォーマンステストでは、テスト中のコードやテストハーネス/構成を調節しながら複数回実行する必要があります。早めにテストを開始して、複数回反復できる時間を確保してください。 * ご自身のメールプロバイダーアカウントを使い、メールプロバイダーからレート制限を受けることのないよう、事前に十分なメール送信容量があることを確認します。使用しないのであれば、メール送信をオフにします。 * すべてのソーシャル接続では、Auth0の開発者キーでなく、必ずご自身のアカウント資格情報を使ってください。Auth0 dashboardで［Connections（接続）］> ［Social（ソーシャル）］ > {接続名}に移動して、その接続にご自身のソーシャルプロバイダ―アカウント資格情報を追加する手順を確認します。注意：ソーシャルプロバイダーによっては、負荷テストが許可されない場合もあります。お使いのプロバイダーのポリシーをご確認ください。 * レート制限を回避し、より正確に実際の負荷をシミュレートするため、同一ユーザーに全要求を送信するのでなく、複数ユーザーに送信する必要があります。一人または数人のみのユーザーを使うと、キャッシュによって実質的なロードが低下し、現実的な結果が得られない場合があります。 * テストで合意されたパラメーターと、Auth0負荷テストポリシーに必ず従ってください。Auth0は、パフォーマンステストや負荷テストが合意されたパラメーターまたは予定されたテストウィンドウを超えた場合、それらのテストを終了する権利を留保します。 ## プロジェクト計画ガイド 当社では、PDF形式の計画ガイダンスを提供しています。ダウンロードして、推奨される戦略の詳細を参照してください。 [B2C IAM Project Planning Guide](https://assets.ctfassets.net/cdy7uua7fh8z/3er1aEQ7Ul0q3c9leJWczR/b1f18b4c16abb7e78b01e4eb2b52bb8e/B2C_Project_Planning.pdf)