End-to-end Test
エンドツーエンドテスト
エンドツーエンド(E2E)テストは、組み立てられ配置されたシステムを通じて、完全なユーザーまたはビジネスのジャーニーを追います。
もう一つの例
テスターはテストアカウントでサインインし、1つの商品を購入し、安全なテスト決済サービスを通じて支払います。注文は確認ページと注文履歴に表示される必要があります。注文関数を直接呼び出すと、エンドツーエンドの流れが省略されます。
主な部分
- 01ユーザージャーニー
- 02組み立て済みシステム
- 03可観測な結果
以下の場合に使用します
全製品にわたって機能する必要があるいくつかの重要なジョーニーには、この用語を使用します。
以下の場合は使用しないでください
すべてのケースを遅いE2Eテストで確認せず、ランダムに失敗するテストを受け入れないでください。
コードで使用する名前
browser → app → service → data → UI 出荷前に
Check the environment and prepared test data (fixture). Define a result you can observe, failure and edge cases, isolation, stable inputs, useful error details, and cleanup. Set a time budget, owner, and flaky-test rule.
Outcome:Complete the task with エンドツーエンドテスト (End-to-end Test)。 User context:テスターはテストアカウントでサインインし、1つの商品を購入し、安全なテスト決済サービスを通じて支払います。注文は確認ページと注文履歴に表示される必要があります。注文関数を直接呼び出すと、エンドツーエンドの流れが省略されます。 Validation approach:エンドツーエンドテスト (End-to-end Test)。 Why it fits:全製品にわたって機能する必要があるいくつかの重要なジョーニーには、この用語を使用します。 Do not use it when:すべてのケースを遅いE2Eテストで確認せず、ランダムに失敗するテストを受け入れないでください。 Test requirements: Name the system and test environment. Define prepared test data, other inputs, and the result you can observe. Include failure and edge cases, allowed error, isolation, and cleanup. Test operations: Make failures easy to diagnose. Control random or changing inputs. Name an owner. Keep the test fast and simple enough for its release gate. Acceptance criteria: The test fails for the known bug and passes after the fix. It repeats in the target environment, gives useful evidence, and does not expose or change unrelated data. Evidence and limits (evidence boundary):その情報源にとって公式です。他のプラットフォームやチームはその用語を別の方法で使用する場合があります。 Unknowns to confirm: Release gate, environment, prepared test data, allowed error, time budget, owner, and flaky-test rule.
このリクエストを確認する
Review how エンドツーエンドテスト (End-to-end Test) is used now. Definition: エンドツーエンド(E2E)テストは、組み立てられ配置されたシステムを通じて、完全なユーザーまたはビジネスのジャーニーを追います。 Release checks: Check the environment and prepared test data (fixture). Define a result you can observe, failure and edge cases, isolation, stable inputs, useful error details, and cleanup. Set a time budget, owner, and flaky-test rule. Before changing code, list the evidence, gaps, severity, and the smallest safe fix.