# User Story
身為 銀行客戶
我想要 轉帳給其他帳戶
以便 快速完成付款

# Example Mapping 產出的範例
範例1: 正常轉帳
  Given 我的帳戶有 10,000 元
  When 我轉帳 5,000 元給朋友
  Then 我的帳戶應該剩下 5,000 元

範例2: 餘額不足
  Given 我的帳戶有 3,000 元
  When 我轉帳 5,000 元給朋友
  Then 應該顯示「餘額不足」錯誤

# features/transfer.feature
Feature: 銀行轉帳功能
  身為銀行客戶,我需要能夠將資金轉移到其他帳戶

  Background:
    Given 我已經登入網路銀行
    And 我的帳戶餘額為 10000 元

  Scenario: 成功轉帳
    When 我轉帳 3000 元到帳戶 "9876543210"
    Then 交易應該成功
    And 我的帳戶餘額應該是 7000 元
    And 對方帳戶應該增加 3000 元

  Scenario: 餘額不足時無法轉帳
    When 我轉帳 15000 元到帳戶 "9876543210"
    Then 應該看到錯誤訊息 "餘額不足"
    And 我的帳戶餘額應該仍是 10000 元

# steps/transfer_steps.py
from behave import given, when, then

@given('我的帳戶餘額為 {amount:d} 元')
def step_impl(context, amount):
    context.account = BankAccount(balance=amount)

@when('我轉帳 {amount:d} 元到帳戶 "{target}"')
def step_impl(context, amount, target):
    context.result = context.account.transfer(amount, target)

@then('我的帳戶餘額應該是 {expected:d} 元')
def step_impl(context, expected):
    assert context.account.balance == expected

核心提問清單:
1. 正常情況下會發生什麼?(Happy Path)
2. 什麼情況下會失敗?(異常處理)
3. 邊界在哪裡?(邊界條件)
4. 有哪些業務規則?(規則驗證)
5. 與其他系統的互動?(整合點)
6. 效能要求是什麼?(非功能需求)
7. 安全考量有哪些?(安全需求)

🟨 [Story]
身為銀行客戶
我想要轉帳給其他帳戶
以便快速付款給朋友或商家

├─ 🟦 [Rule 1] 餘額必須足夠
│  ├─ 🟩 [Example] 餘額 10,000,轉帳 5,000 → 成功,剩 5,000
│  ├─ 🟩 [Example] 餘額 3,000,轉帳 5,000 → 失敗,顯示「餘額不足」
│  └─ 🟩 [Example] 餘額 5,000,轉帳 5,000 → 成功,剩 0
│
├─ 🟦 [Rule 2] 每日轉帳限額 10 萬元
│  ├─ 🟩 [Example] 當日已轉 8 萬,再轉 1 萬 → 成功(總計 9 萬)
│  ├─ 🟩 [Example] 當日已轉 9.5 萬,再轉 1 萬 → 失敗,顯示「超過每日限額」
│  └─ 🟥 [Question] 限額是否包含跨行轉帳?
│
├─ 🟦 [Rule 3] 收款帳號必須有效
│  ├─ 🟩 [Example] 輸入正確帳號 → 顯示戶名供確認
│  ├─ 🟩 [Example] 輸入錯誤帳號 → 顯示「查無此帳號」
│  └─ 🟥 [Question] 是否驗證收款銀行的營業狀態?
│
└─ 🟥 [Question] 轉帳失敗時是否發送通知?

✅ Ready for Development (可以開發)
- 有明確的業務規則
- 每個規則有具體範例
- 紅色卡片少於 3 張
- 團隊對需求有共識

⚠️ Need More Discovery (需要更多探索)
- 紅色卡片太多(>3張)
- 規則不明確或有衝突
- 範例難以產生

🔴 Too Big (Story 太大)
- 超過 8 個規則
- 會議超時仍無法完成
- 建議:拆分成多個小 Story

[Virtual Board Layout]

🟨 Story
┌────────────────────────────────────┐
│ 身為...我想要...以便...            │
└────────────────────────────────────┘

🟦 Rule 1          🟦 Rule 2          🟦 Rule 3
┌──────────────┐  ┌──────────────┐  ┌──────────────┐
│ 業務規則描述  │  │ 業務規則描述  │  │ 業務規則描述  │
└──────────────┘  └──────────────┘  └──────────────┘
       ↓                   ↓                   ↓
🟩 Example 1-1    🟩 Example 2-1    🟩 Example 3-1
🟩 Example 1-2    🟩 Example 2-2    
🟩 Example 1-3    

🟥 Questions
┌────────────────────────────────────┐
│ ? 問題 1                            │
│ ? 問題 2                            │
└────────────────────────────────────┘

🟩 餘額 10,000,轉帳 5,000 → 成功,剩 5,000
🟩 餘額 3,000,轉帳 5,000 → 失敗,顯示「餘額不足」

Scenario: 餘額足夠時成功轉帳
  Given 我的帳戶餘額為 10000 元
  When 我轉帳 5000 元給朋友
  Then 轉帳應該成功
  And 我的帳戶餘額應該是 5000 元

Scenario: 餘額不足時轉帳失敗
  Given 我的帳戶餘額為 3000 元
  When 我轉帳 5000 元給朋友
  Then 轉帳應該失敗
  And 應該顯示錯誤訊息 "餘額不足"

# 功能描述(Feature)
Feature: 簡短標題
  作為 [角色]
  我想要 [功能]
  以便 [業務價值]

  # 背景(可選)
  Background: 共同的前置條件
    Given 預設狀態

  # 場景(Scenario)
  Scenario: 場景名稱
    Given 前置條件
    When 執行動作
    Then 預期結果
    
  # 場景大綱(資料驅動)
  Scenario Outline: 場景模板
    Given 帳戶餘額為 <餘額> 元
    When 轉帳 <金額> 元
    Then 結果應為 <結果>
    
    Examples:
      | 餘額  | 金額  | 結果 |
      | 10000 | 5000  | 成功 |
      | 3000  | 5000  | 失敗 |

優先級排序:
1. 🔴 核心正常流程(Happy Path)
2. 🟠 常見異常情況
3. 🟡 邊界條件
4. 🟢 特殊業務規則
5. 🔵 非功能需求驗證

# ✅ 好的範例:清楚、具體、可測試
Scenario: 首次購買享有新客折扣
  Given 我是新註冊的會員
  And 購物車有商品總價 1000 元
  When 我結帳時
  Then 應該自動套用 100 元新客折扣
  And 實際付款金額應該是 900 元

# ❌ 不好的範例:模糊、無法測試
Scenario: 購買優惠
  Given 使用者
  When 買東西
  Then 有折扣

# 問題:
# - 什麼樣的使用者?
# - 買什麼東西?多少錢?
# - 什麼折扣?多少金額?

# ❌ 技術導向
Given 資料庫有一筆 user_id=123 的記錄
When POST /api/transfer with {"amount":5000}
Then HTTP 200 and database updated

# ✅ 業務導向
Given 我的帳戶餘額為 10000 元
When 我轉帳 5000 元給朋友
Then 轉帳應該成功
And 我的帳戶餘額應該是 5000 元

# ❌ 太多行為混在一起
Scenario: 購物流程
  Given 我瀏覽商品
  When 我加入購物車
  And 我修改數量
  And 我輸入優惠碼
  And 我選擇付款方式
  And 我確認訂單
  Then 訂單成立
  # 問題:太長,難以維護

# ✅ 拆分為多個 Scenario
Scenario: 將商品加入購物車
Scenario: 修改購物車商品數量
Scenario: 套用優惠碼
Scenario: 確認訂單並付款

# ❌ 過於關注 UI
Given 我點擊左上角的選單按鈕
When 我在第二個欄位輸入 "5000"
And 我點擊藍色的"確認"按鈕

# ✅ 關注業務行為
Given 我開啟轉帳功能
When 我輸入轉帳金額 5000 元
And 我確認轉帳

# Feature File (Gherkin)
Scenario: 成功轉帳
  Given 我的帳戶餘額為 10000 元
  When 我轉帳 5000 元給帳戶 "9876543210"
  Then 我的帳戶餘額應該是 5000 元

# Step Definitions (Python + Behave)
from behave import given, when, then

@given('我的帳戶餘額為 {amount:d} 元')
def step_set_balance(context, amount):
    context.account = BankAccount()
    context.account.set_balance(amount)

@when('我轉帳 {amount:d} 元給帳戶 "{target}"')
def step_transfer(context, amount, target):
    context.result = context.account.transfer(amount, target)

@then('我的帳戶餘額應該是 {expected:d} 元')
def step_verify_balance(context, expected):
    assert context.account.get_balance() == expected

# 基本模式
@given('前置條件')
def setup():
    # 準備測試資料
    # 設定系統狀態
    pass

@when('執行動作')
def action():
    # 執行測試操作
    # 記錄結果
    pass

@then('驗證結果')
def verify():
    # 斷言檢查
    # 比對預期與實際
    pass

# 執行 BDD 測試
behave features/

# 執行特定 Feature
behave features/transfer.feature

# 執行特定 Scenario
behave features/transfer.feature:10

功能: 銀行轉帳
  ✓ 餘額足夠時成功轉帳
  ✓ 餘額不足時轉帳失敗
  ✗ 超過每日限額時轉帳失敗
    Expected: "超過每日限額"
    Actual: "餘額不足"

2 scenarios passed, 1 failed, 0 skipped
15 steps passed, 1 failed, 3 skipped

# ✅ 可重用、參數化、清晰
@given('帳戶餘額為 {amount:d} 元')
def step_set_balance(context, amount):
    context.account.set_balance(amount)

@given('帳戶餘額為 {amount:d} 元且每日已轉 {daily_used:d} 元')
def step_set_balance_with_daily_limit(context, amount, daily_used):
    context.account.set_balance(amount)
    context.account.set_daily_transferred(daily_used)

# ❌ 硬編碼、不可重用
@given('帳戶有一萬元')
def step_impl(context):
    context.account.set_balance(10000)

@given('帳戶有五千元')
def step_impl(context):
    context.account.set_balance(5000)
# 問題:每個金額都要寫一個新的 step

# ✅ 好的:簡潔明瞭
@when('我轉帳 {amount:d} 元')
def step_impl(context, amount):
    context.result = context.account.transfer(amount)

# ❌ 不好的:包含太多邏輯
@when('我轉帳 {amount:d} 元')
def step_impl(context, amount):
    # 檢查餘額
    if context.account.balance < amount:
        context.result = False
    else:
        # 扣款
        context.account.balance -= amount
        # 記錄交易
        context.account.add_transaction(amount)
        # 發送通知
        send_notification()
    # 應該將這些邏輯放在應用程式層

# Page Object
class TransferPage:
    def input_amount(self, amount):
        self.driver.find_element(By.ID, "amount").send_keys(amount)
    
    def input_target_account(self, account):
        self.driver.find_element(By.ID, "target").send_keys(account)
    
    def click_submit(self):
        self.driver.find_element(By.ID, "submit").click()

# Step Definition
@when('我轉帳 {amount:d} 元給帳戶 "{target}"')
def step_impl(context, amount, target):
    page = TransferPage(context.driver)
    page.input_amount(amount)
    page.input_target_account(target)
    page.click_submit()

# ✅ Feature 層次:業務語言
Given 我是一般會員
When 我購買商品總價 1000 元
Then 我應該獲得 10 點紅利

# ✅ Step Definition 層次:測試邏輯
@given('我是一般會員')
def step_impl(context):
    context.user = create_user(membership='regular')

# ✅ Helper 層次:技術細節
def create_user(membership):
    return User.objects.create(
        username='test_user',
        membership_level=membership
    )

# 功能 (Feature)
Feature: 功能標題
  功能說明
  可以是多行

  # 背景 (Background) - 可選
  Background: 共同前置條件
    Given 共同的設定
  
  # 場景 (Scenario)
  Scenario: 場景描述
    Given 前置條件
    And 更多前置條件
    When 執行操作
    And 更多操作
    Then 預期結果
    And 更多結果
    But 不應該發生的事
  
  # 場景大綱 (Scenario Outline)
  Scenario Outline: 場景模板
    Given <參數1>
    When <參數2>
    Then <參數3>
    
    Examples:
      | 參數1 | 參數2 | 參數3 |
      | 值1   | 值2   | 值3   |

Feature: 使用者登入
  作為註冊會員
  我想要登入系統
  以便使用會員專屬功能

Feature: 轉帳功能

  Background: 使用者已登入
    Given 我已經登入網路銀行
    And 系統已連線正常

Scenario: 成功登入
  Given 我在登入頁面
  And 我有有效的帳號密碼
  When 我輸入正確的帳號密碼
  And 我點擊登入按鈕
  Then 我應該看到會員首頁
  And 頁面應該顯示我的名字

Given 我的帳戶餘額為 10000 元
And 今天是 2025-01-15
And 系統匯率為 1 USD = 30 TWD

When 我轉帳 5000 元給朋友
And 我確認交易

Then 我的帳戶餘額應該是 5000 元
And 我應該收到轉帳成功通知
And 交易記錄應該顯示此筆轉帳

# And:增加相同類型的步驟
Given 我已登入
And 我在轉帳頁面
And 我的帳戶有 10000 元

# But:描述不應該發生的事
Then 轉帳應該成功
But 對方不應該收到簡訊通知

Scenario Outline: 轉帳金額驗證
  Given 我的帳戶餘額為 <餘額> 元
  When 我轉帳 <金額> 元
  Then 結果應該是 <結果>
  And 餘額應該是 <剩餘> 元
  
  Examples:
    | 餘額  | 金額  | 結果 | 剩餘 |
    | 10000 | 5000  | 成功 | 5000 |
    | 10000 | 10000 | 成功 | 0    |
    | 5000  | 10000 | 失敗 | 5000 |
    | 1000  | 999   | 成功 | 1    |

Examples: 正常情況
  | 餘額  | 金額 | 結果 |
  | 10000 | 100  | 成功 |
  | 5000  | 200  | 成功 |

Examples: 異常情況
  | 餘額 | 金額  | 結果 |
  | 100  | 1000  | 失敗 |
  | 0    | 100   | 失敗 |

Feature: 功能名稱         # 不縮排
  說明文字              # 縮排 2 空格(可選)
  
  Background:           # 縮排 2 空格
    Given 步驟          # 縮排 4 空格
    
  Scenario: 場景       # 縮排 2 空格
    Given 步驟          # 縮排 4 空格
    When 步驟           # 縮排 4 空格
    Then 步驟           # 縮排 4 空格

# 這是註解,會被解析器忽略

Feature: 轉帳功能  # 行尾註解也可以

# Scenario: 這個場景被註解掉了
#   Given 步驟
#   When 步驟

Scenario: 發送通知郵件
  When 系統發送郵件內容為:
    """
    親愛的客戶:
    
    您的轉帳已成功完成。
    金額:5000 元
    時間:2025-01-15 10:30
    
    感謝您的使用。
    """
  Then 郵件應該成功發送

Scenario: 批次轉帳
  Given 我有以下轉帳清單:
    | 收款人   | 帳號       | 金額 |
    | 張三     | 1234567890 | 1000 |
    | 李四     | 0987654321 | 2000 |
    | 王五     | 5555555555 | 1500 |
  When 我執行批次轉帳
  Then 所有轉帳應該成功

@smoke @critical
Feature: 登入功能

@happy_path
Scenario: 正常登入

@error_handling @slow
Scenario: 密碼錯誤

@wip
Scenario: 開發中的功能

# 只執行有 @smoke 標籤的場景
cucumber --tags @smoke

# 排除 @wip 標籤
cucumber --tags "not @wip"

# 組合條件
cucumber --tags "@smoke and not @slow"

Scenario: [場景描述]
  Given [前置條件]
  When [執行動作]
  Then [預期結果]

Scenario Outline: [場景描述]
  Given [前置條件] <參數>
  When [執行動作] <參數>
  Then [預期結果] <參數>
  
  Examples:
    | 參數 |
    | 值1  |
    | 值2  |

@feature_tag
Feature: 功能簡短標題
  作為 [使用者角色]
  我想要 [功能描述]
  以便 [達成的價值或目標]
  
  # 額外說明(可選)
  這個功能用於處理...
  相關業務規則包括...
  
  # 業務規則說明
  Business Rules:
  - 規則 1
  - 規則 2
  
  Background:
    # 共同前置條件
  
  Scenario: 場景 1
  Scenario: 場景 2

# ✅ 好的命名:簡潔、業務導向
Feature: 使用者登入
Feature: 銀行轉帳
Feature: 購物車結帳
Feature: 訂單退款處理

# ❌ 不好的命名:太技術、太長、不清楚
Feature: LoginController.login() 方法測試
Feature: 使用者可以透過輸入帳號密碼並點擊登入按鈕來登入系統
Feature: 測試
Feature: Feature1

Feature: 線上退貨申請
  作為 已購買商品的客戶
  我想要 透過網站申請退貨
  以便 快速處理退款,無需電話聯繫客服

Feature: 即時庫存查詢
  提供客戶即時的商品庫存資訊,
  避免下單後才發現缺貨,
  提升客戶購物體驗與滿意度。

Feature: 密碼重設
  允許忘記密碼的使用者透過電子郵件重設密碼。

# ✅ 好的範例:職責單一
Scenario: 餘額足夠時轉帳成功
  Given 我的帳戶餘額為 10000 元
  When 我轉帳 5000 元給朋友
  Then 轉帳應該成功
  And 我的餘額應該是 5000 元

Scenario: 餘額不足時轉帳失敗
  Given 我的帳戶餘額為 3000 元
  When 我轉帳 5000 元給朋友
  Then 應該顯示「餘額不足」錯誤
  And 我的餘額應該仍是 3000 元

# ❌ 不好的範例:混合多個職責
Scenario: 轉帳測試
  Given 我的帳戶餘額為 10000 元
  When 我轉帳 5000 元
  Then 轉帳成功
  When 我再轉帳 6000 元
  Then 轉帳失敗
  When 我查詢餘額
  Then 餘額是 5000 元

Feature: 商品下單

  # 1. 先寫 Happy Path
  @happy_path
  Scenario: 成功下單並付款
    Given 我已登入
    And 購物車有商品總價 1000 元
    When 我選擇信用卡付款並確認訂單
    Then 訂單應該建立成功
    And 我應該收到訂單確認郵件
  
  # 2. 再補充異常流程
  @error_handling
  Scenario: 未登入時無法下單
    Given 我未登入
    And 購物車有商品
    When 我嘗試下單
    Then 應該導向登入頁面
  
  @error_handling
  Scenario: 購物車為空時無法下單
    Given 我已登入
    And 購物車是空的
    When 我嘗試下單
    Then 應該顯示「購物車為空」錯誤

Feature: 會員點數查詢

  Background: 會員已登入
    Given 我以會員身分登入
    And 我在會員中心頁面
  
  Scenario: 查詢目前點數
    When 我查看點數餘額
    Then 應該顯示我的點數為 500 點
  
  Scenario: 查詢點數歷史記錄
    When 我查看點數歷史
    Then 應該顯示最近 10 筆點數異動記錄
  
  Scenario: 查詢點數即將到期資訊
    Given 我有 200 點將在 30 天內到期
    When 我查看點數到期提醒
    Then 應該顯示到期點數警告

# ✅ 好的命名:描述業務行為與結果
Scenario: 首次購買享有新客優惠
Scenario: 連續登入失敗三次後帳號鎖定
Scenario: VIP 會員免運費
Scenario: 超過退貨期限無法申請退貨

# ❌ 不好的命名:太簡略或太技術
Scenario: 測試 1
Scenario: 正常情況
Scenario: API 回傳 200
Scenario: 資料庫查詢成功

Scenario Outline: 驗證轉帳金額限制
  Given 我的帳戶餘額為 <餘額> 元
  When 我轉帳 <金額> 元
  Then 結果應為 <結果>
  And 餘額應為 <最終餘額> 元
  
  Examples:
    | 餘額  | 金額  | 結果 | 最終餘額 |
    | 10000 | 5000  | 成功 | 5000     |
    | 10000 | 10000 | 成功 | 0        |
    | 5000  | 10000 | 失敗 | 5000     |

Scenario Outline: 使用者註冊驗證
  Given 我在註冊頁面
  When 我輸入電子郵件 "<email>"
  Then 結果應為 "<結果>"
  
  Examples: 有效的電子郵件
    | email                  | 結果 |
    | user@example.com       | 成功 |
    | user.name@example.com  | 成功 |
    | user+tag@example.co.uk | 成功 |
  
  Examples: 無效的電子郵件
    | email           | 結果             |
    | invalid         | 格式錯誤         |
    | @example.com    | 格式錯誤         |
    | user@           | 格式錯誤         |
    | user @email.com | 格式錯誤         |
  
  Examples: 已註冊的電子郵件
    | email              | 結果         |
    | existing@email.com | 電子郵件已存在 |

Scenario Outline: 轉帳金額邊界測試
  Given 我的帳戶餘額為 10000 元
  When 我轉帳 <金額> 元
  Then 結果應為 <結果>
  
  Examples: 邊界值分析
    | 金額  | 結果         | 說明           |
    | 0     | 失敗         | 最小值以下     |
    | 1     | 成功         | 最小有效值     |
    | 9999  | 成功         | 最大值以下     |
    | 10000 | 成功         | 最大有效值     |
    | 10001 | 失敗(餘額不足)| 最大值以上     |
    | 50001 | 失敗(超過限額)| 遠超過最大值   |

Scenario Outline: 訂單折扣計算
  Given 我是 <會員等級> 會員
  And 購物車商品總價 <原價> 元
  And 使用優惠碼 "<優惠碼>"
  When 我結帳
  Then 折扣金額應為 <折扣> 元
  And 實付金額應為 <實付> 元
  
  Examples:
    | 會員等級 | 原價 | 優惠碼    | 折扣 | 實付 |
    | 一般     | 1000 | 無        | 0    | 1000 |
    | 一般     | 1000 | SAVE100   | 100  | 900  |
    | VIP      | 1000 | 無        | 100  | 900  |
    | VIP      | 1000 | SAVE100   | 200  | 800  |
    | VIP      | 5000 | VIP500    | 1000 | 4000 |

Scenario: 批次建立使用者
  When 我批次建立以下使用者:
    | 姓名   | 電子郵件          | 角色   |
    | 張三   | zhang@email.com   | 管理員 |
    | 李四   | li@email.com      | 編輯   |
    | 王五   | wang@email.com    | 檢視者 |
  Then 應該成功建立 3 個使用者
  And 每個使用者應該收到歡迎郵件

需求:會員購物折扣系統

系統需要根據會員等級提供不同的購物折扣:
- 一般會員:無折扣
- 銀卡會員:9折
- 金卡會員:85折
- 白金卡會員:8折

另外,如果訂單金額超過3000元,額外再享95折。
這個折扣是在會員折扣之後再計算的。

特殊情況:
- 折扣後金額不得低於100元
- 已使用優惠碼的訂單不再享有會員折扣

🟦 規則 1:會員等級折扣
🟦 規則 2:滿額優惠(>3000 元享 95 折)
🟦 規則 3:最低消費金額限制(≥100 元)
🟦 規則 4:優惠碼與會員折扣互斥

🟩 一般會員,訂單 1000 元 → 1000 元
🟩 銀卡會員,訂單 1000 元 → 900 元
🟩 金卡會員,訂單 2000 元 → 1700 元
🟩 金卡會員,訂單 4000 元 → 3230 元(4000×0.85×0.95)
🟩 白金卡會員,訂單 200 元 → 160 元
🟩 白金卡會員,訂單 120 元 → 100 元(最低限制)
🟩 使用優惠碼的訂單 → 不享會員折扣

Feature: 會員購物折扣系統
  作為 電商系統
  我需要 根據會員等級計算折扣
  以便 提供會員專屬優惠並鼓勵消費
  
  Business Rules:
  - 會員等級折扣:一般(無)、銀卡(9折)、金卡(85折)、白金卡(8折)
  - 滿額優惠:訂單 >3000 元額外享 95 折
  - 最低消費:折扣後不得低於 100 元
  - 優惠碼與會員折扣互斥

  Background:
    Given 購物車有商品
    And 準備結帳

  @happy_path
  Scenario Outline: 根據會員等級計算折扣
    Given 我是 <會員等級> 會員
    And 訂單金額為 <原價> 元
    When 系統計算折扣
    Then 折扣後金額應為 <最終金額> 元
    
    Examples: 基本會員折扣
      | 會員等級 | 原價 | 最終金額 | 說明              |
      | 一般     | 1000 | 1000     | 無折扣            |
      | 銀卡     | 1000 | 900      | 9折               |
      | 金卡     | 2000 | 1700     | 85折              |
      | 白金卡   | 1000 | 800      | 8折               |

  @complex_discount
  Scenario Outline: 會員折扣加上滿額優惠
    Given 我是 <會員等級> 會員
    And 訂單金額為 <原價> 元
    When 系統計算折扣
    Then 會員折扣後為 <會員折扣後> 元
    And 再享滿額優惠為 <滿額優惠後> 元
    And 最終金額為 <最終金額> 元
    
    Examples: 滿額優惠計算
      | 會員等級 | 原價 | 會員折扣後 | 滿額優惠後 | 最終金額 |
      | 金卡     | 4000 | 3400       | 3230       | 3230     |
      | 白金卡   | 5000 | 4000       | 3800       | 3800     |
      | 銀卡     | 3500 | 3150       | 2993       | 2993     |

  @boundary
  Scenario: 折扣後金額不得低於最低消費
    Given 我是白金卡會員
    And 訂單金額為 120 元
    When 系統計算折扣
    Then 按會員等級應折扣為 96 元
    But 因最低消費限制,最終金額為 100 元
    And 應該顯示提示「已達最低消費金額」

  @business_rule
  Scenario: 使用優惠碼時不享會員折扣
    Given 我是金卡會員
    And 訂單金額為 2000 元
    And 我使用了優惠碼 "SPECIAL200"
    When 系統計算折扣
    Then 應該套用優惠碼折扣 200 元
    And 不應該套用會員折扣
    And 最終金額為 1800 元

  @error_handling
  Scenario: 嘗試同時使用優惠碼與會員折扣
    Given 我是金卡會員
    And 訂單金額為 2000 元
    And 我使用了優惠碼 "SAVE100"
    When 系統嘗試同時套用兩種折扣
    Then 應該顯示訊息「優惠碼與會員折扣僅能擇一使用」
    And 提示我選擇較優惠的方案

  @edge_cases
  Scenario Outline: 邊界值測試
    Given 我是金卡會員
    And 訂單金額為 <原價> 元
    When 系統計算折扣
    Then 最終金額為 <最終金額> 元
    
    Examples: 滿額優惠臨界點
      | 原價 | 最終金額 | 說明                    |
      | 2999 | 2549     | 未滿3000,無滿額優惠     |
      | 3000 | 2423     | 剛好3000,享滿額優惠     |
      | 3001 | 2423     | 超過3000,享滿額優惠     |
    
    Examples: 最低消費臨界點
      | 原價 | 最終金額 | 說明                    |
      | 117  | 100      | 折扣後<100,取最低消費   |
      | 118  | 100      | 折扣後=100,剛好最低消費 |
      | 119  | 101      | 折扣後>100,正常計算     |

# ❌ 錯誤:充滿技術細節
Scenario: 測試 API
  Given 資料庫有一筆 id=123 的 user 記錄
  When 發送 POST /api/transfer 
    And request body = {"from":123,"to":456,"amount":5000}
  Then HTTP status code = 200
  And response.data.balance = 5000

# ✅ 正確:使用業務語言
Scenario: 成功轉帳給朋友
  Given 我的帳戶餘額為 10000 元
  When 我轉帳 5000 元給朋友的帳戶
  Then 轉帳應該成功
  And 我的帳戶餘額應該是 5000 元

# ❌ 錯誤:綁定 UI 實作
Scenario: 登入系統
  Given 我打開瀏覽器訪問 http://example.com/login
  When 我在 id="username" 的輸入框輸入 "user123"
  And 我在第二個輸入框輸入密碼
  And 我點擊 class="btn-primary" 的藍色按鈕
  Then 應該跳轉到 /dashboard 頁面

# ✅ 正確:關注業務行為
Scenario: 成功登入系統
  Given 我在登入頁面
  When 我輸入有效的帳號密碼
  And 我點擊登入按鈕
  Then 應該進入會員首頁
  And 應該看到歡迎訊息

# ❌ 錯誤:步驟太籠統
Scenario: 購物
  Given 使用者
  When 買東西
  Then 成功

# ✅ 正確:步驟明確具體
Scenario: 成功完成商品購買
  Given 我已登入為註冊會員
  And 購物車有 2 件商品,總價 1500 元
  When 我選擇信用卡付款
  And 我確認訂單
  Then 訂單應該建立成功
  And 我應該收到訂單編號
  And 應該收到訂單確認郵件

# ❌ 錯誤:一個 Scenario 測試太多東西
Scenario: 完整的購物流程
  Given 我註冊新帳號
  When 我登入
  And 我瀏覽商品
  And 我加入購物車
  And 我修改數量
  And 我使用優惠碼
  And 我結帳
  And 我付款
  And 我查詢訂單
  Then 一切正常

# ✅ 正確:拆分為多個 Scenario
Scenario: 新會員註冊
Scenario: 會員登入
Scenario: 將商品加入購物車
Scenario: 使用優惠碼結帳
Scenario: 查詢訂單狀態

# ❌ 錯誤:順序混亂
Scenario: 轉帳
  When 我轉帳 5000 元
  Then 轉帳成功
  Given 我的帳戶有 10000 元

# ✅ 正確:遵循正確順序
Scenario: 餘額足夠時轉帳成功
  Given 我的帳戶餘額為 10000 元
  When 我轉帳 5000 元給朋友
  Then 轉帳應該成功
  And 我的餘額應該是 5000 元

撰寫給業務人員看的規格,而非給程式設計師看的測試程式碼

用具體範例說明,勝過抽象的規則描述

80% 正確且易讀的規格,勝過 100% 完整但複雜的規格

Feature Files 不是文件,是可執行的規格

隨著理解加深,不斷精煉與重構 Feature Files

Feature: [功能名稱]
  作為 [角色]
  我想要 [功能]
  以便 [價值]

  Scenario: [正常情況]
    Given [前置條件]
    When [執行動作]
    Then [預期結果]
  
  Scenario: [異常情況]
    Given [前置條件]
    When [執行動作]
    Then [錯誤處理]

Feature: [功能名稱]

  Scenario Outline: [場景描述]
    Given [前置] <參數1>
    When [動作] <參數2>
    Then [結果] <參數3>
    
    Examples:
      | 參數1 | 參數2 | 參數3 |
      | 值1   | 值2   | 值3   |

Feature: [功能名稱]

  Background:
    Given [共同前置條件]
  
  @happy_path
  Scenario: [主要成功路徑]
  
  @alternative_path
  Scenario: [替代路徑]
  
  @error_handling
  Scenario: [錯誤處理]
  
  @boundary
  Scenario Outline: [邊界測試]

傳統做法:
1. 收集使用者需求
2. 撰寫需求規格書(SRS)
3. 評審與簽核
4. 交付開發團隊

BDD 做法:
1. 收集使用者需求
2. 識別關鍵使用者故事
3. Discovery Workshop(協作探索)
4. 產出 Example Map 與 Feature Files
5. 持續協作與調整

需求:系統應該支援使用者管理功能,
包括新增、修改、刪除使用者,
並且需要權限控管。

行為:建立使用者
規則:帳號必須唯一

範例:
✅ 當帳號不存在時,成功建立使用者
❌ 當帳號已存在時,顯示「帳號已存在」錯誤
❌ 當帳號格式不正確時,顯示「帳號格式錯誤」

Feature: 使用者管理 - 建立使用者
  作為 系統管理員
  我想要 建立新的使用者帳號
  以便 讓新員工可以使用系統

  Background:
    Given 我以管理員身分登入
    And 我在使用者管理頁面

  @happy_path
  Scenario: 成功建立新使用者
    When 我建立使用者,資料如下:
      | 帳號     | email@example.com |
      | 姓名     | 張三              |
      | 部門     | 資訊部            |
      | 角色     | 一般使用者        |
    Then 使用者應該建立成功
    And 系統應該發送歡迎郵件到 email@example.com
    And 使用者清單應該顯示新使用者

  @validation
  Scenario: 帳號已存在時無法建立
    Given 系統已有帳號 "existing@example.com"
    When 我嘗試建立帳號 "existing@example.com"
    Then 應該顯示錯誤訊息 "帳號已存在"
    And 使用者不應該被建立

  @validation
  Scenario Outline: 驗證必填欄位
    When 我建立使用者,但 <欄位> 為空
    Then 應該顯示錯誤訊息 "<錯誤訊息>"
    
    Examples:
      | 欄位 | 錯誤訊息           |
      | 帳號 | 帳號為必填欄位     |
      | 姓名 | 姓名為必填欄位     |
      | 部門 | 部門為必填欄位     |

  @authorization
  Scenario: 非管理員無法建立使用者
    Given 我以一般使用者身分登入
    When 我嘗試建立新使用者
    Then 應該顯示錯誤訊息 "權限不足"
    And 應該導向首頁

原始需求:
使用者應該能夠重設忘記的密碼

轉換為 BDD:
Feature: 密碼重設
  Scenario: 透過電子郵件重設密碼
    Given 我忘記了密碼
    When 我在登入頁面點擊「忘記密碼」
    And 我輸入註冊的電子郵件
    Then 我應該收到密碼重設連結
    When 我點擊連結並輸入新密碼
    Then 密碼應該更新成功
    And 我應該能用新密碼登入

原始需求:
訂單金額超過 1000 元免運費,
未滿 1000 元運費 100 元

轉換為 BDD:
Feature: 運費計算規則
  Scenario Outline: 根據訂單金額計算運費
    Given 購物車商品總價為 <金額> 元
    When 系統計算運費
    Then 運費應為 <運費> 元
    And 訂單總金額應為 <總額> 元
    
    Examples:
      | 金額 | 運費 | 總額 |
      | 500  | 100  | 600  |
      | 999  | 100  | 1099 |
      | 1000 | 0    | 1000 |
      | 1500 | 0    | 1500 |

原始需求:
當訂單成立時,系統需要通知倉儲系統進行出貨

轉換為 BDD:
Feature: 訂單與倉儲系統整合
  Scenario: 訂單成立後通知倉儲系統
    Given 購物車有商品
    When 我完成訂單並付款成功
    Then 訂單狀態應為「待出貨」
    And 系統應該發送出貨通知到倉儲系統
    And 倉儲系統應該接收到以下資訊:
      | 訂單編號 | ORD-20250107-001 |
      | 收件人   | 張三             |
      | 收件地址 | 台北市...        |
      | 商品清單 | [商品明細]       |

原始需求:
系統回應時間應在 2 秒內

轉換為 BDD:
Feature: 系統效能要求
  @performance
  Scenario: 查詢使用者清單的回應時間
    Given 資料庫有 10000 筆使用者資料
    When 我查詢使用者清單(第一頁,每頁50筆)
    Then 回應時間應少於 2 秒
    And 應該回傳 50 筆使用者資料

□ 選擇要探索的 User Story
□ 準備 Story 的背景資料
□ 預先識別可能的業務規則
□ 準備幾個初步範例
□ 預約會議室/線上會議
□ 準備工具(便利貼、白板 or Miro)
□ 發送會議邀請與前置資料

會議:Example Mapping Workshop - [Story 名稱]
時間:60 分鐘
參與者:PO、領域專家、SA、Dev、QA

目標:
1. 理解 Story 的業務需求
2. 識別業務規則
3. 產生具體範例
4. 達成共識

請攜帶:
- 對此功能的任何問題
- 相關的業務知識與經驗

前置資料:[連結]

1. Story 背景:為什麼需要這個功能?
2. 使用者角色:誰會使用?
3. 業務價值:達成什麼目標?
4. 初步驗收準則

引導問句:
- 「在什麼情況下會...?」
- 「有哪些限制或條件?」
- 「什麼時候會失敗?」
- 「是否有例外情況?」
- 「與其他功能的關聯?」

記錄方式:
- 每個規則寫在一張藍色卡片
- 簡潔描述,一句話為主
- 放在 Story 卡片下方

範例產生技巧:
1. 先問「正常情況是什麼?」
2. 再問「什麼時候會出錯?」
3. 探索邊界「剛好」的情況
4. 考慮組合情境

記錄方式:
- 每個範例一張綠色卡片
- 寫明輸入與預期輸出
- 放在對應規則下方

記錄問題:
- 無法當場回答的問題
- 需要進一步調查的技術限制
- 需要決策層決定的事項
- 與其他團隊確認的整合點

記錄方式:
- 紅色卡片記錄問題
- 標註負責人
- 設定回覆期限

評估準則:
✅ Ready:
   - 規則清楚(< 8 個)
   - 範例充足(每個規則至少 2 個)
   - 紅色卡片少(< 3 個)
   - 團隊理解一致

⚠️ Need Work:
   - 紅色卡片多(>= 3 個)
   - 規則模糊或衝突
   - 範例難以產生
   → 安排後續會議

🔴 Too Big:
   - 規則太多(> 8 個)
   - Workshop 時間不夠
   → 拆分為多個 Story

SA 的工作:
□ 將 Example Map 轉為 Feature File
□ 整理會議記錄
□ 追蹤紅色卡片的問題解決

Dev 的工作:
□ 評估技術可行性
□ 提供實作時間估算

QA 的工作:
□ Review Feature File
□ 補充測試場景

PO 的工作:
□ 解決業務決策問題
□ 確認優先順序

身為 行銷人員
我想要 建立限時促銷活動
以便 吸引客戶下單並提升營業額

驗收準則:
- 可設定促銷期間
- 可選擇適用商品
- 可設定折扣方式(百分比/固定金額)

🟨 [Story] 建立限時促銷活動

├─ 🟦 [Rule 1] 促銷期間必須是未來時間
│  ├─ 🟩 開始時間=今天 23:00,結束=明天 23:59 → 成功
│  ├─ 🟩 開始時間=昨天,結束=明天 → 失敗「開始時間不可為過去」
│  └─ 🟥 [Q] 是否允許建立但暫不啟用的活動?
│
├─ 🟦 [Rule 2] 結束時間必須晚於開始時間
│  ├─ 🟩 開始=2025-01-10, 結束=2025-01-15 → 成功
│  ├─ 🟩 開始=2025-01-10 10:00, 結束=2025-01-10 09:00 → 失敗
│  └─ 🟩 開始=結束 → 失敗「結束時間必須晚於開始時間」
│
├─ 🟦 [Rule 3] 必須選擇至少一個商品
│  ├─ 🟩 選擇 3 個商品 → 成功
│  ├─ 🟩 選擇全部商品 → 成功
│  ├─ 🟩 未選擇商品 → 失敗「請選擇至少一個商品」
│  └─ 🟥 [Q] 是否支援選擇商品類別?
│
├─ 🟦 [Rule 4] 折扣方式:百分比(1-99%)或固定金額
│  ├─ 🟩 百分比 20% → 成功
│  ├─ 🟩 固定金額 100 元 → 成功
│  ├─ 🟩 百分比 0% → 失敗「折扣必須大於0」
│  ├─ 🟩 百分比 100% → 失敗「折扣不可為100%」
│  └─ 🟩 固定金額大於商品價格 → 警告「折扣金額不應超過商品價格」
│
├─ 🟦 [Rule 5] 同一商品不可有重疊的促銷活動
│  ├─ 🟩 商品 A 活動 1:1/1-1/10, 活動 2:1/11-1/20 → 成功
│  ├─ 🟩 商品 A 活動 1:1/1-1/10, 活動 2:1/5-1/15 → 失敗
│  └─ 🟥 [Q] 如果重疊,是否自動套用較優惠的活動?
│
└─ 🟥 [Q] 是否需要活動預覽功能?

Feature: 電商促銷活動管理
  作為 行銷人員
  我想要 建立限時促銷活動
  以便 吸引客戶購買並提升營業額

  Background:
    Given 我以行銷人員身分登入
    And 我在促銷活動管理頁面

  @happy_path
  Scenario: 成功建立促銷活動
    When 我建立促銷活動,資訊如下:
      | 活動名稱 | 新年特惠         |
      | 開始時間 | 2025-01-10 00:00 |
      | 結束時間 | 2025-01-15 23:59 |
      | 適用商品 | 商品A, 商品B     |
      | 折扣方式 | 百分比 20%       |
    Then 活動應該建立成功
    And 活動狀態應為「待啟用」
    And 活動清單應顯示新活動

  @validation
  Scenario Outline: 驗證促銷期間
    When 我設定開始時間為 <開始時間>
    And 我設定結束時間為 <結束時間>
    Then 結果應為 <結果>
    
    Examples: 時間驗證
      | 開始時間         | 結束時間         | 結果                     |
      | 昨天             | 明天             | 失敗:開始時間不可為過去   |
      | 明天             | 今天             | 失敗:結束時間必須晚於開始 |
      | 今天 10:00       | 今天 10:00       | 失敗:結束時間必須晚於開始 |
      | 明天             | 後天             | 成功                     |

  @validation
  Scenario Outline: 驗證折扣設定
    Given 商品價格為 1000 元
    When 我設定折扣方式為 <折扣方式> <折扣值>
    Then 結果應為 <結果>
    And 折扣後價格應為 <折扣後價格> 元
    
    Examples: 折扣驗證
      | 折扣方式 | 折扣值 | 結果     | 折扣後價格 |
      | 百分比   | 20%    | 成功     | 800        |
      | 百分比   | 0%     | 失敗     | -          |
      | 百分比   | 100%   | 失敗     | -          |
      | 固定金額 | 100    | 成功     | 900        |
      | 固定金額 | 1000   | 警告     | 0          |
      | 固定金額 | 1500   | 警告     | -          |

  @business_rule
  Scenario: 同一商品不可有重疊促銷活動
    Given 商品A 已有促銷活動 "春節特惠" 期間為 2025-01-01 至 2025-01-10
    When 我建立新活動 "新年優惠" 期間為 2025-01-05 至 2025-01-15
    And 我選擇商品A
    Then 應該顯示錯誤訊息 "商品A 在此期間已有促銷活動"
    And 應該列出衝突的活動 "春節特惠"

  @edge_case
  Scenario: 促銷活動不可選擇已下架商品
    Given 商品B 已下架
    When 我建立促銷活動並選擇商品B
    Then 應該顯示警告 "商品B 已下架"
    And 應該詢問是否繼續

身為 [使用者角色]
我想要 [功能/目標]
以便 [獲得的價值/原因]

驗收準則:
- 準則 1
- 準則 2
- 準則 3

身為 網站訪客
我想要 註冊成為會員
以便 享有會員專屬優惠與服務

驗收準則:
- 必須提供有效的電子郵件
- 密碼至少 8 個字元
- 註冊成功後發送驗證郵件
- 重複的電子郵件無法註冊

Feature: 會員註冊
  身為 網站訪客
  我想要 註冊成為會員
  以便 享有會員專屬優惠與服務

  @happy_path
  Scenario: 成功註冊新會員
    Given 我在註冊頁面
    When 我輸入有效的註冊資訊:
      | 電子郵件 | newuser@example.com |
      | 密碼     | SecurePass123       |
      | 姓名     | 張三                |
    And 我同意服務條款
    And 我點擊註冊按鈕
    Then 註冊應該成功
    And 我應該收到驗證郵件到 newuser@example.com
    And 應該顯示訊息「請檢查您的電子郵件以驗證帳號」

  @validation
  Scenario Outline: 驗證電子郵件格式
    Given 我在註冊頁面
    When 我輸入電子郵件 "<email>"
    Then 驗證結果應為 "<結果>"
    
    Examples:
      | email                | 結果     |
      | valid@example.com    | 有效     |
      | invalid.email        | 格式錯誤 |
      | @example.com         | 格式錯誤 |
      | user@                | 格式錯誤 |

  @validation
  Scenario Outline: 驗證密碼強度
    Given 我在註冊頁面
    When 我輸入密碼 "<password>"
    Then 驗證結果應為 "<結果>"
    
    Examples:
      | password    | 結果                   |
      | Pass123     | 失敗:至少8個字元       |
      | Password    | 失敗:必須包含數字      |
      | 12345678    | 失敗:必須包含字母      |
      | Pass1234    | 成功                   |

  @business_rule
  Scenario: 重複電子郵件無法註冊
    Given 系統已有會員 "existing@example.com"
    When 我嘗試註冊帳號 "existing@example.com"
    Then 應該顯示錯誤訊息 "此電子郵件已被註冊"
    And 註冊不應該成功

# ✅ 好:每個 Feature 獨立
Feature: 會員註冊
Feature: 會員登入
Feature: 密碼重設

# ❌ 不好:Feature 之間有依賴
Feature: 會員管理
  Scenario: 先註冊
  Scenario: 再登入
  Scenario: 然後修改資料

在 Discovery Workshop 中:
- 業務:「註冊後應該立即登入」
- Dev:「需要先驗證電子郵件嗎?」
- SA:「讓我們加入這兩個場景」

產出:
  Scenario: 註冊後自動登入(未驗證狀態)
  Scenario: 驗證電子郵件後啟用完整功能

# ✅ 好:突顯價值
Feature: 快速結帳
  作為 回購客戶
  我想要 使用先前儲存的付款資訊
  以便 快速完成結帳,不必每次輸入

# ❌ 不好:只描述功能
Feature: 儲存信用卡資訊
  系統應該儲存信用卡

Feature: 訂單取消
  
  # 清楚的範例讓估算更準確
  Scenario: 訂單成立30分鐘內可取消
  Scenario: 已出貨的訂單無法取消
  Scenario: 取消訂單後自動退款
  Scenario: VIP會員24小時內可取消
  
  # 從範例數量與複雜度可評估工作量

# ❌ 太大
Feature: 完整的訂單管理系統

# ✅ 拆分為小 Feature
Feature: 建立訂單
Feature: 修改訂單
Feature: 取消訂單
Feature: 查詢訂單
Feature: 訂單狀態追蹤

# ✅ 可測試:明確的輸入與預期輸出
Scenario: 計算訂單折扣
  Given 購物車總價 1000 元
  And 使用優惠碼 "SAVE100"
  When 我結帳
  Then 折扣金額應為 100 元
  And 實付金額應為 900 元

# ❌ 難測試:模糊不清
Scenario: 優惠計算
  When 用戶結帳
  Then 應該有折扣

訂單取消功能驗收準則:
1. 使用者可以取消訂單
2. 取消後應退款
3. 已出貨的訂單不能取消
4. 系統應記錄取消原因

Feature: 訂單取消

  Scenario: 訂單成立後30分鐘內可取消並全額退款
    Given 我的訂單編號為 "ORD001"
    And 訂單金額為 1500 元
    And 訂單成立時間為 15 分鐘前
    When 我取消訂單並選擇原因「不想買了」
    Then 訂單狀態應變更為「已取消」
    And 應該全額退款 1500 元到原付款方式
    And 系統應記錄取消原因「不想買了」

  Scenario: 超過30分鐘後取消需扣除手續費
    Given 我的訂單成立於 2 小時前
    And 訂單金額為 1500 元
    When 我申請取消訂單
    Then 應該顯示「將扣除10%手續費」
    When 我確認取消
    Then 應退款 1350 元(扣除 150 元手續費)

  Scenario: 已出貨的訂單無法取消
    Given 我的訂單狀態為「已出貨」
    When 我嘗試取消訂單
    Then 應該顯示「訂單已出貨,無法取消」
    And 應該提示「您可以申請退貨」

# ✅ 結構清晰
Given [前置條件]
When [使用者動作]
Then [預期結果]

# ❌ 結構混亂
「使用者應該可以...」
「系統應該...」

# ✅ 單一行為
Scenario: VIP會員享免運費
  Given 我是VIP會員
  When 我結帳
  Then 運費應為 0 元

# ❌ 多個行為混雜
Scenario: 會員權益
  Given 我是VIP會員
  Then 享免運費
  And 享9折
  And 獲得雙倍點數
  And 優先客服
  # 應拆分為4個 Scenario

Feature: 轉帳功能
  
  # 正常情況
  @happy_path
  Scenario: 餘額足夠時成功轉帳
  
  # 異常情況
  @error_handling
  Scenario: 餘額不足時轉帳失敗
  Scenario: 帳號不存在時轉帳失敗
  Scenario: 超過每日限額時轉帳失敗
  Scenario: 系統維護時無法轉帳

# ✅ 明確具體
Given 我的帳戶餘額為 10000 元
When 我轉帳 5000 元
Then 我的餘額應該是 5000 元

# ❌ 模糊不清
Given 我的帳戶有錢
When 我轉帳一些錢
Then 餘額應該減少

# ✅ 業務語言
Given 我是銀卡會員
When 購物滿 1000 元
Then 享有 9 折優惠

# ❌ 技術語言
Given user.membership_level = 'SILVER'
When cart.total >= 1000
Then apply_discount(0.9)

Use Case: UC-001 會員登入

參與者:註冊會員

前置條件:
- 會員已完成註冊
- 會員未登入

主要流程:
1. 會員開啟登入頁面
2. 系統顯示登入表單
3. 會員輸入帳號密碼
4. 會員點擊登入按鈕
5. 系統驗證帳號密碼
6. 系統顯示會員首頁

替代流程 3a:密碼錯誤
3a1. 系統顯示「帳號或密碼錯誤」
3a2. 回到步驟 3

替代流程 3b:帳號不存在
3b1. 系統顯示「帳號不存在」
3b2. 回到步驟 3

替代流程 3c:帳號被鎖定
3c1. 系統顯示「帳號已被鎖定,請聯繫客服」
3c2. Use Case 結束

後置條件:
- 會員成功登入
- 系統記錄登入時間

Feature: 會員登入
  作為 註冊會員
  我想要 登入網站
  以便 使用會員專屬功能

  Background:
    Given 我已完成註冊
    And 我目前未登入狀態
    And 我在登入頁面

  @happy_path @UC-001
  Scenario: 成功登入系統
    When 我輸入正確的帳號 "user@example.com"
    And 我輸入正確的密碼 "SecurePass123"
    And 我點擊登入按鈕
    Then 我應該成功登入
    And 應該導向會員首頁
    And 應該顯示歡迎訊息 "歡迎回來,張三"
    And 系統應該記錄登入時間

  @error_handling @UC-001-3a
  Scenario: 密碼錯誤無法登入
    Given 我的正確密碼是 "CorrectPass"
    When 我輸入帳號 "user@example.com"
    And 我輸入錯誤密碼 "WrongPass"
    And 我點擊登入按鈕
    Then 應該顯示錯誤訊息 "帳號或密碼錯誤"
    And 我應該仍在登入頁面
    And 密碼欄位應該被清空

  @error_handling @UC-001-3b
  Scenario: 不存在的帳號無法登入
    When 我輸入帳號 "nonexist@example.com"
    And 我輸入密碼 "AnyPassword"
    And 我點擊登入按鈕
    Then 應該顯示錯誤訊息 "帳號不存在"
    And 應該提供「立即註冊」連結

  @error_handling @UC-001-3c
  Scenario: 帳號鎖定時無法登入
    Given 我的帳號 "locked@example.com" 已被鎖定
    When 我嘗試登入
    Then 應該顯示錯誤訊息 "帳號已被鎖定,請聯繫客服"
    And 應該提供客服聯絡方式
    And 不應該允許繼續嘗試登入

  @security
  Scenario: 連續3次密碼錯誤後鎖定帳號
    Given 我的帳號是 "user@example.com"
    And 我已經輸入錯誤密碼 2 次
    When 我第3次輸入錯誤密碼
    Then 應該顯示「帳號已被鎖定,請 30 分鐘後再試」
    And 帳號狀態應變更為「暫時鎖定」
    And 應該發送通知郵件到 user@example.com

專案結構:
├─ docs/
│  └─ use-cases/
│     ├─ UC-001-會員登入.md
│     ├─ UC-002-商品搜尋.md
│     └─ UC-003-訂單結帳.md
│
├─ features/
│  ├─ login.feature          # 對應 UC-001
│  ├─ product_search.feature # 對應 UC-002
│  └─ checkout.feature       # 對應 UC-003
│
└─ README.md
   說明:Use Case 提供業務背景,
        Feature File 是可執行規格

@UC-001 @login
Feature: 會員登入

  @UC-001-main @happy_path
  Scenario: 主要流程 - 成功登入

  @UC-001-3a @error_handling
  Scenario: 替代流程 3a - 密碼錯誤

  @UC-001-3b @error_handling
  Scenario: 替代流程 3b - 帳號不存在

不要一開始就全面導入BDD
✅ 選擇 1-2 個簡單功能試點
✅ 累積經驗後逐步擴大
✅ 建立團隊信心與共識

BDD 的核心是協作,不是工具
✅ 先建立協作文化
✅ 工具是輔助,不是目的
✅ 紙筆也能做 Example Mapping

不要追求完美的規格
✅ 80% 正確優於 100% 完整
✅ 可以持續迭代改進
✅ 優先涵蓋核心場景

標準化可提升效率
✅ 建立 Feature 範本
✅ 整理常用範例模式
✅ 分享最佳實務

□ SA 準備:
  - 列印或分享 User Story
  - 準備初步的 Example Map(如有)
  - 準備便利貼與白板

□ 參與者準備:
  - 閱讀 User Story
  - 思考可能的問題

BA/SA 說明:
1. Story 背景與業務價值
2. 主要使用者與使用情境
3. 已知的驗收準則
4. 業務優先級與期望

輪流提問:
→ BA 提問:澄清業務邏輯
   「如果使用者是 VIP,流程有差異嗎?」
   「這個折扣規則適用所有商品嗎?」

→ Dev 提問:技術可行性
   「需要整合其他系統嗎?」
   「預期的資料量級是?」
   「效能要求是?」

→ QA 提問:測試場景
   「邊界值是多少?」
   「同時發生會如何?」
   「失敗後如何回復?」

協作產出:
1. 識別業務規則(藍色卡片)
2. 為每個規則產生範例(綠色卡片)
3. 記錄問題與假設(紅色卡片)
4. 確保三方都理解與同意

決定:
□ Story 是否 Ready for Development
□ 需要進一步澄清的問題
□ 後續工作分配:
  - SA: 撰寫 Feature File
  - Dev: 評估技術方案
  - QA: 準備測試資料
□ 下次會議時間(如需要)

SA 工作:
□ 將 Example Map 拍照/數位化保存
□ 撰寫 Feature File
□ 分享給團隊 Review

Dev 工作:
□ 研究技術方案
□ 提供工作量估算

QA 工作:
□ Review Feature File
□ 準備測試環境與資料

身為 註冊會員
我想要 使用點數兌換商品
以便 獲得購物優惠

驗收準則:
- 100 點可兌換 10 元折扣
- 點數不足時無法兌換
- 兌換後點數立即扣除

BA:「這個功能主要是鼓勵會員累積點數,提升忠誠度」

SA:「我們先確認規則,100點換10元,那200點可以換20元嗎?」

BA:「對,按比例計算,但有個上限,單筆訂單最多用1000點」

QA:「如果我有1500點,訂單金額500元,會發生什麼?」

BA:「最多用1000點,換100元,所以實付400元,剩下500點」

Dev:「點數扣除的時機是?下單時?還是付款成功後?」

BA:「應該是付款成功後才扣,如果取消訂單要還回去」

QA:「那如果付款失敗呢?點數不扣?」

BA:「對,付款失敗或取消都不扣點數」

Dev:「這需要交易機制確保一致性,技術上需要...」

SA:「等等,我們先把這些規則記下來:
     規則1: 點數兌換比例 100:10
     規則2: 單筆訂單上限 1000 點
     規則3: 付款成功後才扣點
     規則4: 取消訂單退還點數」

QA:「邊界情況:如果訂單金額50元,但我用1000點呢?」

BA:「好問題!折扣不能超過訂單金額,所以50元訂單最多扣500點」

Dev:「效能考量:點數查詢和扣除需要即時嗎?可接受的延遲是?」

BA:「查詢要即時,扣除可以有幾秒延遲,但要給使用者回饋」

SA:「我記錄一個問題:點數有效期限嗎?」

BA:「有,點數1年後過期,這可能是另一個 Story」

QA:「並發問題:兩個訂單同時用點數會不會超扣?」

Dev:「需要鎖定機制,這是技術細節,我們可以處理」

SA:「好,我們現在有 4 個主要規則和 8 個範例,我會寫成 Feature」

🟨 [Story] 會員點數兌換商品

├─ 🟦 [Rule 1] 點數兌換比例 100:10(100點換10元)
│  ├─ 🟩 有 1000點,兌換 100元 → 成功,剩 0點
│  ├─ 🟩 有 500點,兌換 50元 → 成功,剩 0點
│  └─ 🟩 有 50點,嘗試兌換 → 失敗「點數不足」
│
├─ 🟦 [Rule 2] 單筆訂單點數使用上限 1000點
│  ├─ 🟩 有 1500點,訂單 500元,用 1000點 → 成功,折扣100元,剩500點
│  ├─ 🟩 有 800點,訂單 500元,用 800點 → 成功,折扣80元,剩0點
│  └─ 🟥 [Q] 如果會員等級不同,上限是否不同?
│
├─ 🟦 [Rule 3] 折扣不得超過訂單金額
│  ├─ 🟩 訂單 50元,有 1000點 → 只扣 500點(折扣50元),剩500點
│  └─ 🟩 訂單 10元,有 100點 → 只扣 100點(折扣10元),剩0點
│
├─ 🟦 [Rule 4] 付款成功後才扣點數
│  ├─ 🟩 下單用點 → 付款成功 → 點數扣除
│  ├─ 🟩 下單用點 → 付款失敗 → 點數不扣
│  └─ 🟩 下單用點 → 取消訂單 → 點數退還
│
└─ 🟥 [Q] 點數扣除的延遲可接受範圍?(已確認:幾秒內)

Feature: 會員點數兌換折扣
  作為 註冊會員
  我想要 使用累積的點數兌換折扣
  以便 節省購物費用

  Business Rules:
  - 兌換比例:100 點 = 10 元
  - 單筆訂單上限:1000 點
  - 折扣不得超過訂單金額
  - 付款成功後才扣除點數

  Background:
    Given 我已登入為註冊會員
    And 我在結帳頁面

  @happy_path
  Scenario: 成功使用點數兌換折扣
    Given 我的點數餘額為 1000 點
    And 購物車商品總價為 500 元
    When 我選擇使用 500 點兌換
    Then 應該折扣 50 元
    And 實付金額應為 450 元
    When 我完成付款
    Then 點數餘額應為 500 點

  @validation
  Scenario Outline: 點數兌換計算
    Given 我的點數餘額為 <點數> 點
    And 購物車商品總價為 <訂單金額> 元
    When 我選擇使用 <使用點數> 點兌換
    Then 結果應為 <結果>
    And 折扣金額應為 <折扣> 元
    And 實付金額應為 <實付> 元
    
    Examples:
      | 點數 | 訂單金額 | 使用點數 | 結果 | 折扣 | 實付 |
      | 1000 | 500      | 500      | 成功 | 50   | 450  |
      | 500  | 500      | 500      | 成功 | 50   | 450  |
      | 100  | 500      | 500      | 失敗 | 0    | 500  |

  @business_rule
  Scenario: 單筆訂單點數使用上限 1000 點
    Given 我的點數餘額為 1500 點
    And 購物車商品總價為 500 元
    When 我選擇使用 1500 點兌換
    Then 應該顯示提示「單筆訂單最多使用 1000 點」
    And 應該自動調整為 1000 點
    And 折扣金額應為 100 元

  @business_rule
  Scenario: 折扣金額不得超過訂單金額
    Given 我的點數餘額為 1000 點
    And 購物車商品總價為 50 元
    When 我選擇使用 1000 點兌換
    Then 應該顯示提示「折扣金額不可超過訂單金額」
    And 應該自動調整為 500 點
    And 折扣金額應為 50 元
    And 實付金額應為 0 元

  @payment_flow
  Scenario: 付款成功後扣除點數
    Given 我的點數餘額為 500 點
    And 我選擇使用 300 點兌換
    And 訂單金額為 400 元(折扣30元後實付370元)
    When 我完成信用卡付款並成功
    Then 點數應該扣除 300 點
    And 點數餘額應為 200 點
    And 我應該收到點數異動通知

  @payment_flow
  Scenario: 付款失敗時不扣點數
    Given 我的點數餘額為 500 點
    And 我選擇使用 300 點兌換
    When 我嘗試付款但失敗
    Then 點數不應該被扣除
    And 點數餘額應仍為 500 點
    And 應該顯示「付款失敗,點數未使用」

  @cancellation
  Scenario: 取消訂單時退還點數
    Given 我的訂單使用了 300 點兌換
    And 付款已成功,點數已扣除
    When 我在 30 分鐘內取消訂單
    Then 300 點應該退還到我的帳戶
    And 我應該收到點數退還通知

Morning (09:00-12:00)
├─ 09:00-09:30  檢視昨日測試結果
├─ 09:30-10:30  參與 Daily Standup + 澄清問題
├─ 10:30-11:30  撰寫/精煉 Feature Files
└─ 11:30-12:00  Review 開發中的 Step Definitions

Afternoon (13:00-18:00)
├─ 13:00-14:00  Discovery Workshop(視需要)
├─ 14:00-15:00  Three Amigos 會議
├─ 15:00-17:00  撰寫文件/更新規格
└─ 17:00-18:00  驗收測試/缺陷追蹤

Week Overview:
├─ Monday
│  ├─ Sprint Planning(如適用)
│  ├─ 選擇本週 Stories
│  └─ 安排 Discovery Workshops
│
├─ Tuesday-Thursday
│  ├─ Discovery Workshops
│  ├─ 撰寫 Feature Files
│  ├─ Three Amigos Reviews
│  └─ 支援開發團隊
│
└─ Friday
   ├─ 驗收測試
   ├─ 週報告整理
   └─ Sprint Review(如適用)

# features/[feature_name].feature
@[feature_tag] @[module]
Feature: [功能名稱]
  作為 [使用者角色]
  我想要 [功能描述]
  以便 [業務價值]
  
  # 業務規則說明(可選)
  Business Rules:
  - 規則 1
  - 規則 2
  
  # 相關文件(可選)
  References:
  - User Story: US-001
  - Use Case: UC-001
  - 業務文件: [連結]

  Background: [共同前置條件描述]
    Given [步驟 1]
    And [步驟 2]

  @happy_path @[priority]
  Scenario: [正常情況描述]
    Given [前置條件]
    When [執行動作]
    Then [預期結果]

  @validation @[tag]
  Scenario Outline: [驗證場景描述]
    Given [前置條件] <參數>
    When [動作] <參數>
    Then [結果] <參數>
    
    Examples: [資料描述]
      | 參數1 | 參數2 | 參數3 |
      | 值1   | 值2   | 值3   |

  @error_handling
  Scenario: [異常處理描述]
    Given [前置條件]
    When [觸發異常的動作]
    Then [錯誤處理結果]

# Example Map: [Story 名稱]

**日期**: 2025-01-15
**參與者**: BA(張三)、SA(李四)、Dev(王五)、QA(趙六)
**Story ID**: US-123

## User Story

## 業務規則與範例

### 規則 1: [規則描述]
- ✅ 範例 1: [具體範例]
- ✅ 範例 2: [具體範例]
- ✅ 範例 3: [具體範例]

### 規則 2: [規則描述]
- ✅ 範例 1: [具體範例]
- ✅ 範例 2: [具體範例]

### 規則 3: [規則描述]
- ✅ 範例 1: [具體範例]

## 待釐清問題
1. ❓ [問題描述] - 負責人:[姓名] - 期限:[日期]
2. ❓ [問題描述] - 負責人:[姓名] - 期限:[日期]

## 技術考量
- [技術點 1]
- [技術點 2]

## 決議
- [ ] Story 狀態: Ready / Need Work / Too Big
- [ ] 後續行動:
  - SA: 撰寫 Feature File
  - Dev: 評估技術方案
  - QA: 準備測試資料

## 附件
- Example Map 照片: [連結]
- 相關文件: [連結]

# Three Amigos 會議記錄

**Story**: US-123 - [Story 名稱]
**日期**: 2025-01-15 14:00-15:00
**參與者**: 
- BA: 張三
- SA: 李四
- Dev: 王五、劉七
- QA: 趙六

## 會議目標
Review Feature File 並確認實作方向

## 討論重點

### 1. 規則澄清
**問題**: [描述]
**討論**: [過程]
**結論**: [決議]

### 2. 技術可行性
**問題**: [描述]
**Dev 意見**: [說明]
**決議**: [方案]

### 3. 測試場景補充
**QA 建議**: [場景]
**決議**: 新增 Scenario: [名稱]

## 行動項目
- [ ] SA: 更新 Feature File - 期限: 2025-01-16
- [ ] Dev: 提供技術設計文件 - 期限: 2025-01-17
- [ ] QA: 準備測試資料 - 期限: 2025-01-18

## 更新的 Feature File
[連結或內嵌 Feature File]

## 下次會議
時間: [日期時間]
議題: [主題]

project/
├── src/
│   └── [應用程式碼]
│
├── features/                    # Feature Files 目錄
│   ├── authentication/
│   │   ├── login.feature
│   │   ├── logout.feature
│   │   └── password_reset.feature
│   │
│   ├── user_management/
│   │   ├── create_user.feature
│   │   ├── update_user.feature
│   │   └── delete_user.feature
│   │
│   └── order_processing/
│       ├── create_order.feature
│       ├── cancel_order.feature
│       └── refund.feature
│
├── steps/                       # Step Definitions
│   ├── authentication_steps.py
│   ├── user_management_steps.py
│   └── order_steps.py
│
├── docs/
│   ├── example_maps/           # Example Map 記錄
│   └── meeting_notes/          # 會議記錄
│
└── README.md

# 1. 為每個 Story 建立分支
git checkout -b feature/US-123-user-login

# 2. 撰寫 Feature File
# 編輯 features/authentication/login.feature

# 3. 提交 Feature File
git add features/authentication/login.feature
git commit -m "feat: 新增使用者登入 Feature File (US-123)"

# 4. 實作 Step Definitions
git add steps/authentication_steps.py
git commit -m "feat: 實作登入 Step Definitions (US-123)"

# 5. 實作功能程式碼
git add src/authentication/
git commit -m "feat: 實作使用者登入功能 (US-123)"

# 6. 推送並建立 Pull Request
git push origin feature/US-123-user-login

格式:
<type>(<scope>): <subject>

類型(type):
- feat: 新功能(Feature 或程式碼)
- fix: 修復錯誤
- docs: 文件更新(包含 Feature File)
- refactor: 重構(Feature 或程式碼)
- test: 測試相關
- chore: 雜項

範例:
feat(login): 新增使用者登入 Feature File (US-123)
feat(login): 實作登入 Step Definitions (US-123)
feat(login): 實作登入 API endpoint (US-123)
docs(login): 更新登入 Feature 說明 (US-123)
refactor(login): 重構登入 Scenario,拆分為多個小場景
fix(login): 修正密碼驗證邏輯的 Feature 描述

✅ 應該做:
- 納入版本控管
- Code Review
- 自動化執行
- 持續維護更新

❌ 不應該:
- 當作一次性文件
- 允許過時不更新
- 與程式碼分開管理

需求變更流程:
1. BA 提出變更需求
2. 召開 Three Amigos 討論
3. 更新 Feature File
4. Review 並確認
5. 實作變更
6. 執行測試驗證
7. 提交變更(Feature + Code)

重構時機:
□ Scenario 太長(>15 步)
□ 重複的步驟過多
□ Feature 包含太多 Scenario(>15 個)
□ Background 過於複雜
□ 不再使用的舊場景

重構方法:
- 提取共用步驟到 Background
- 拆分大 Feature 為多個小 Feature
- 使用 Scenario Outline 合併相似場景
- 移除已廢棄的場景
- 更新過時的業務術語

# 使用標籤標記狀態

@wip
Scenario: 開發中的功能
  # Work In Progress

@skip @bug-123
Scenario: 暫時跳過的測試
  # 等待 Bug-123 修復

@deprecated
Scenario: 即將移除的舊功能
  # 將在下個版本移除

@manual
Scenario: 手動測試場景
  # 暫時無法自動化

@slow
Scenario: 執行緩慢的測試
  # 僅在夜間執行

## Feature File Review Checklist

### 結構與格式
- [ ] Feature 描述清楚,包含業務價值
- [ ] 使用正確的 Gherkin 語法
- [ ] 縮排與格式一致
- [ ] 標籤使用恰當

### 內容品質
- [ ] 使用業務語言,避免技術細節
- [ ] 每個 Scenario 職責單一
- [ ] Given-When-Then 結構正確
- [ ] 步驟明確且可測試

### 覆蓋度
- [ ] 包含 Happy Path
- [ ] 包含主要異常情況
- [ ] 包含邊界條件
- [ ] 包含業務規則驗證

### 可維護性
- [ ] Background 使用恰當
- [ ] Scenario Outline 使用合理
- [ ] 沒有重複的場景
- [ ] 易於理解與修改

### 整合性
- [ ] 與 User Story 對應
- [ ] 標籤與專案規範一致
- [ ] 與現有 Feature 無衝突
- [ ] Step Definitions 可實作

### 商業邏輯
- [ ] 符合業務需求
- [ ] 驗收準則完整
- [ ] 與利害關係人達成共識

BDD 的核心是協作,不是自動化測試
✅ 重視 Discovery 與 Three Amigos
✅ 建立跨職能溝通文化
✅ 工具是輔助,不是目的

不要一次導入所有流程
✅ 選擇 1-2 個團隊試點
✅ 選擇簡單功能練習
✅ 累積經驗後擴大

定期回顧與調整流程
✅ Sprint Retrospective 討論 BDD
✅ 收集團隊回饋
✅ 優化瓶頸環節

爭取管理層的理解與支持
✅ 展示 BDD 的價值
✅ 提供數據證明效益
✅ 給予團隊學習時間

選擇 Cucumber (Java/JS/Ruby):
✅ 需要最廣泛的社群支持
✅ 豐富的插件與整合
✅ 跨語言團隊
✅ 企業級專案

選擇 Behave (Python):
✅ Python 開發團隊
✅ 簡單易學
✅ 快速上手
✅ 與 Python 測試工具整合

選擇 SpecFlow (.NET/C#):
✅ .NET 開發團隊
✅ Visual Studio 整合
✅ 企業級 .NET 應用
✅ 需要與 Azure DevOps 整合

選擇 Serenity BDD (Java):
✅ 需要精美的測試報告
✅ 複雜的測試場景
✅ 多層次的測試架構
✅ 與 Jira 整合

# 1. 建立專案目錄
mkdir bdd-demo
cd bdd-demo

# 2. 建立虛擬環境
python -m venv venv

# 3. 啟動虛擬環境
# Windows
venv\Scripts\activate
# Linux/Mac
source venv/bin/activate

# 4. 安裝 Behave
pip install behave

# 5. 安裝其他測試工具(可選)
pip install selenium          # Web UI 測試
pip install requests          # API 測試
pip install allure-behave     # 測試報告
pip install behave-html-formatter  # HTML 報告

# 6. 產生 requirements.txt
pip freeze > requirements.txt

bdd-demo/
├── features/
│   ├── login.feature
│   ├── search.feature
│   └── checkout.feature
│
├── features/steps/
│   ├── __init__.py
│   ├── login_steps.py
│   ├── search_steps.py
│   └── checkout_steps.py
│
├── features/environment.py    # 測試環境設定
│
├── features/pages/            # Page Object (Web UI)
│   ├── __init__.py
│   ├── base_page.py
│   ├── login_page.py
│   └── search_page.py
│
├── features/support/          # 輔助工具
│   ├── __init__.py
│   ├── config.py
│   ├── database.py
│   └── api_client.py
│
├── reports/                   # 測試報告目錄
├── venv/                      # 虛擬環境
├── requirements.txt
├── behave.ini                 # Behave 設定檔
└── README.md

[behave]
# 輸出格式
format = pretty
# 輸出顏色
color = true
# 顯示執行時間
show_timings = true
# 失敗時停止
stop = false
# 標籤表達式
#tags = @smoke and not @skip
# 報告輸出
junit = true
junit_directory = reports/junit
# 並行執行
#processes = 4
# 日誌級別
logging_level = INFO

<!-- pom.xml -->
<project>
    <properties>
        <cucumber.version>7.14.0</cucumber.version>
        <junit.version>5.10.0</junit.version>
    </properties>

    <dependencies>
        <!-- Cucumber Java -->
        <dependency>
            <groupId>io.cucumber</groupId>
            <artifactId>cucumber-java</artifactId>
            <version>${cucumber.version}</version>
        </dependency>

        <!-- Cucumber JUnit -->
        <dependency>
            <groupId>io.cucumber</groupId>
            <artifactId>cucumber-junit</artifactId>
            <version>${cucumber.version}</version>
            <scope>test</scope>
        </dependency>

        <!-- JUnit 5 -->
        <dependency>
            <groupId>org.junit.jupiter</groupId>
            <artifactId>junit-jupiter</artifactId>
            <version>${junit.version}</version>
            <scope>test</scope>
        </dependency>

        <!-- Selenium (Web UI 測試) -->
        <dependency>
            <groupId>org.seleniumhq.selenium</groupId>
            <artifactId>selenium-java</artifactId>
            <version>4.15.0</version>
        </dependency>

        <!-- REST Assured (API 測試) -->
        <dependency>
            <groupId>io.rest-assured</groupId>
            <artifactId>rest-assured</artifactId>
            <version>5.3.2</version>
        </dependency>
    </dependencies>
</project>

cucumber-demo/
├── src/
│   ├── main/
│   │   └── java/
│   │       └── com/example/app/
│   │           └── [應用程式碼]
│   │
│   └── test/
│       ├── java/
│       │   └── com/example/test/
│       │       ├── runners/
│       │       │   └── TestRunner.java
│       │       ├── steps/
│       │       │   ├── LoginSteps.java
│       │       │   ├── SearchSteps.java
│       │       │   └── Hooks.java
│       │       ├── pages/
│       │       │   ├── BasePage.java
│       │       │   └── LoginPage.java
│       │       └── utils/
│       │           └── TestContext.java
│       │
│       └── resources/
│           └── features/
│               ├── login.feature
│               └── search.feature
│
├── target/                    # 編譯輸出
│   └── cucumber-reports/     # 測試報告
├── pom.xml
└── README.md

package com.example.test.runners;

import org.junit.runner.RunWith;
import io.cucumber.junit.Cucumber;
import io.cucumber.junit.CucumberOptions;

@RunWith(Cucumber.class)
@CucumberOptions(
    features = "src/test/resources/features",
    glue = {"com.example.test.steps"},
    tags = "@smoke and not @skip",
    plugin = {
        "pretty",
        "html:target/cucumber-reports/cucumber.html",
        "json:target/cucumber-reports/cucumber.json",
        "junit:target/cucumber-reports/cucumber.xml"
    },
    monochrome = true
)
public class TestRunner {
}

1. Gherkin Parser 讀取 Feature File
2. 解析每個 Step (Given/When/Then)
3. 根據正則表達式或註解匹配 Step Definition
4. 執行對應的測試程式碼
5. 收集執行結果
6. 產生測試報告

# features/login.feature
Feature: 使用者登入

  Scenario: 成功登入
    Given 我在登入頁面
    When 我輸入帳號 "user@example.com"
    And 我輸入密碼 "SecurePass123"
    And 我點擊登入按鈕
    Then 我應該看到會員首頁
    And 頁面應該顯示 "歡迎回來"

# features/steps/login_steps.py
from behave import given, when, then
from selenium import webdriver
from selenium.webdriver.common.by import By

@given('我在登入頁面')
def step_impl(context):
    context.driver = webdriver.Chrome()
    context.driver.get('https://example.com/login')

@when('我輸入帳號 "{username}"')
def step_impl(context, username):
    element = context.driver.find_element(By.ID, 'username')
    element.send_keys(username)

@when('我輸入密碼 "{password}"')
def step_impl(context, password):
    element = context.driver.find_element(By.ID, 'password')
    element.send_keys(password)

@when('我點擊登入按鈕')
def step_impl(context):
    button = context.driver.find_element(By.ID, 'login-btn')
    button.click()

@then('我應該看到會員首頁')
def step_impl(context):
    assert '/dashboard' in context.driver.current_url

@then('頁面應該顯示 "{text}"')
def step_impl(context, text):
    page_text = context.driver.find_element(By.TAG_NAME, 'body').text
    assert text in page_text

// steps/LoginSteps.java
package com.example.test.steps;

import io.cucumber.java.en.Given;
import io.cucumber.java.en.When;
import io.cucumber.java.en.Then;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.By;
import org.openqa.selenium.WebElement;
import static org.junit.Assert.*;

public class LoginSteps {
    private WebDriver driver;
    
    @Given("我在登入頁面")
    public void i_am_on_login_page() {
        driver = new ChromeDriver();
        driver.get("https://example.com/login");
    }
    
    @When("我輸入帳號 {string}")
    public void i_enter_username(String username) {
        WebElement element = driver.findElement(By.id("username"));
        element.sendKeys(username);
    }
    
    @When("我輸入密碼 {string}")
    public void i_enter_password(String password) {
        WebElement element = driver.findElement(By.id("password"));
        element.sendKeys(password);
    }
    
    @When("我點擊登入按鈕")
    public void i_click_login_button() {
        WebElement button = driver.findElement(By.id("login-btn"));
        button.click();
    }
    
    @Then("我應該看到會員首頁")
    public void i_should_see_dashboard() {
        assertTrue(driver.getCurrentUrl().contains("/dashboard"));
    }
    
    @Then("頁面應該顯示 {string}")
    public void page_should_display(String text) {
        String pageText = driver.findElement(By.tagName("body")).getText();
        assertTrue(pageText.contains(text));
    }
}

When 我轉帳 5000 元給朋友

@when('我轉帳 {amount:d} 元給朋友')
def step_impl(context, amount):
    context.result = context.account.transfer(amount, 'friend')

When 我轉帳 5000 元給帳戶 "9876543210"

@when('我轉帳 {amount:d} 元給帳戶 "{target}"')
def step_impl(context, amount, target):
    context.result = context.account.transfer(amount, target)

When 我建立使用者,資料如下:
  | 帳號     | test@example.com |
  | 姓名     | 張三             |
  | 部門     | 資訊部           |

@when('我建立使用者,資料如下:')
def step_impl(context):
    data = {}
    for row in context.table:
        data[row[0]] = row[1]
    context.user = create_user(**data)

When 我發送郵件內容為:
  """
  親愛的客戶:
  
  您的訂單已確認。
  """

@when('我發送郵件內容為:')
def step_impl(context):
    email_body = context.text
    send_email(body=email_body)

# .github/workflows/bdd-tests.yml
name: BDD Tests

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main, develop ]

jobs:
  bdd-tests:
    runs-on: ubuntu-latest
    
    steps:
    - name: Checkout code
      uses: actions/checkout@v3
    
    - name: Set up Python
      uses: actions/setup-python@v4
      with:
        python-version: '3.11'
    
    - name: Install dependencies
      run: |
        pip install -r requirements.txt
    
    - name: Run BDD tests
      run: |
        behave --tags=@smoke --format json -o reports/cucumber.json
      continue-on-error: true
    
    - name: Generate HTML report
      if: always()
      run: |
        behave --format html -o reports/report.html
    
    - name: Publish test results
      if: always()
      uses: actions/upload-artifact@v3
      with:
        name: bdd-test-reports
        path: reports/
    
    - name: Notify on failure
      if: failure()
      uses: 8398a7/action-slack@v3
      with:
        status: ${{ job.status }}
        text: 'BDD Tests Failed!'
        webhook_url: ${{ secrets.SLACK_WEBHOOK }}

# .gitlab-ci.yml
stages:
  - test
  - report

bdd_tests:
  stage: test
  image: python:3.11
  script:
    - pip install -r requirements.txt
    - behave --tags=@smoke --junit --junit-directory reports/
  artifacts:
    when: always
    paths:
      - reports/
    reports:
      junit: reports/*.xml
  only:
    - merge_requests
    - develop
    - main

generate_report:
  stage: report
  dependencies:
    - bdd_tests
  script:
    - behave --format html -o reports/report.html
  artifacts:
    paths:
      - reports/report.html
  when: always

// Jenkinsfile
pipeline {
    agent any
    
    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }
        
        stage('Setup Environment') {
            steps {
                sh '''
                    python -m venv venv
                    . venv/bin/activate
                    pip install -r requirements.txt
                '''
            }
        }
        
        stage('Run BDD Tests') {
            steps {
                sh '''
                    . venv/bin/activate
                    behave --tags=@smoke \
                           --format json -o reports/cucumber.json \
                           --junit --junit-directory reports/
                '''
            }
        }
        
        stage('Publish Results') {
            steps {
                junit 'reports/*.xml'
                publishHTML([
                    reportDir: 'reports',
                    reportFiles: 'report.html',
                    reportName: 'BDD Test Report'
                ])
            }
        }
    }
    
    post {
        failure {
            emailext(
                subject: "BDD Tests Failed: ${env.JOB_NAME}",
                body: "Build failed. Check console output.",
                to: "dev-team@example.com"
            )
        }
    }
}

# features/environment.py
from selenium import webdriver
from selenium.webdriver.chrome.options import Options
import os

def before_all(context):
    """測試套件開始前執行"""
    context.config.setup_logging()
    context.base_url = os.getenv('BASE_URL', 'http://localhost:8000')
    context.api_url = os.getenv('API_URL', 'http://localhost:8000/api')

def before_scenario(context, scenario):
    """每個 Scenario 開始前執行"""
    # 設定瀏覽器
    chrome_options = Options()
    if os.getenv('HEADLESS', 'true') == 'true':
        chrome_options.add_argument('--headless')
    chrome_options.add_argument('--no-sandbox')
    chrome_options.add_argument('--disable-dev-shm-usage')
    
    context.driver = webdriver.Chrome(options=chrome_options)
    context.driver.implicitly_wait(10)
    context.driver.maximize_window()

def after_scenario(context, scenario):
    """每個 Scenario 結束後執行"""
    if hasattr(context, 'driver'):
        # 截圖(如果失敗)
        if scenario.status == 'failed':
            screenshot_name = f"reports/screenshots/{scenario.name}.png"
            context.driver.save_screenshot(screenshot_name)
            print(f"Screenshot saved: {screenshot_name}")
        
        context.driver.quit()

def after_all(context):
    """測試套件結束後執行"""
    # 清理測試資料
    pass

// steps/Hooks.java
package com.example.test.steps;

import io.cucumber.java.Before;
import io.cucumber.java.After;
import io.cucumber.java.Scenario;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.chrome.ChromeOptions;
import org.openqa.selenium.OutputType;
import org.openqa.selenium.TakesScreenshot;

public class Hooks {
    private WebDriver driver;
    
    @Before
    public void setUp() {
        ChromeOptions options = new ChromeOptions();
        if (System.getenv("HEADLESS").equals("true")) {
            options.addArguments("--headless");
        }
        options.addArguments("--no-sandbox");
        options.addArguments("--disable-dev-shm-usage");
        
        driver = new ChromeDriver(options);
        TestContext.setDriver(driver);
    }
    
    @After
    public void tearDown(Scenario scenario) {
        if (scenario.isFailed()) {
            // 截圖
            byte[] screenshot = ((TakesScreenshot) driver)
                .getScreenshotAs(OutputType.BYTES);
            scenario.attach(screenshot, "image/png", scenario.getName());
        }
        
        if (driver != null) {
            driver.quit();
        }
    }
}

# Behave HTML 報告
behave --format html -o reports/report.html

# Allure 報告(更精美)
behave -f allure_behave.formatter:AllureFormatter \
       -o reports/allure-results
allure serve reports/allure-results

behave --format json -o reports/cucumber.json

behave --junit --junit-directory reports/

# 安裝 Allure
pip install allure-behave

# 執行測試並產生 Allure 結果
behave -f allure_behave.formatter:AllureFormatter \
       -o reports/allure-results

# 產生並開啟 Allure 報告
allure serve reports/allure-results

# features/steps/login_steps.py
import allure
from allure_commons.types import AttachmentType

@given('我在登入頁面')
@allure.step('開啟登入頁面')
def step_impl(context):
    context.driver.get(context.base_url + '/login')
    # 附加截圖
    allure.attach(
        context.driver.get_screenshot_as_png(),
        name='登入頁面',
        attachment_type=AttachmentType.PNG
    )

@then('我應該看到會員首頁')
@allure.step('驗證會員首頁顯示')
def step_impl(context):
    assert '/dashboard' in context.driver.current_url
    # 附加頁面 HTML
    allure.attach(
        context.driver.page_source,
        name='會員首頁 HTML',
        attachment_type=AttachmentType.HTML
    )

@JIRA-123 @priority-high
Feature: 使用者登入

  @JIRA-124 @smoke
  Scenario: 成功登入
    Given 我在登入頁面
    When 我輸入正確的帳密
    Then 我應該看到會員首頁

# features/environment.py
import requests

def after_scenario(context, scenario):
    """測試結束後更新 JIRA"""
    # 解析 JIRA Issue ID
    jira_tags = [tag for tag in scenario.tags if tag.startswith('JIRA-')]
    
    if jira_tags:
        jira_id = jira_tags[0].replace('JIRA-', '')
        status = 'Pass' if scenario.status == 'passed' else 'Fail'
        
        # 更新 JIRA
        update_jira_test_result(jira_id, status, scenario.name)

def update_jira_test_result(issue_id, status, test_name):
    """更新 JIRA 測試結果"""
    jira_api = os.getenv('JIRA_API_URL')
    auth = (os.getenv('JIRA_USER'), os.getenv('JIRA_TOKEN'))
    
    comment = f"BDD 測試結果: {status}\n測試: {test_name}"
    
    requests.post(
        f"{jira_api}/rest/api/2/issue/{issue_id}/comment",
        auth=auth,
        json={"body": comment}
    )

作為 電商網站的會員
我想要 登入系統
以便 存取個人化的服務

User Story: 使用者登入
├─ 規則 1: 帳號密碼正確
│  ├─ 範例: 正確帳密 → 成功登入
│  ├─ 範例: 勾選記住我 → 30天免登入
│  └─ 範例: 上次登入時間顯示
│
├─ 規則 2: 帳號密碼驗證
│  ├─ 範例: 帳號不存在 → 顯示錯誤
│  ├─ 範例: 密碼錯誤 → 顯示錯誤
│  ├─ 範例: 空白欄位 → 顯示提示
│  └─ 範例: Email 格式錯誤 → 顯示提示
│
├─ 規則 3: 帳號鎖定機制
│  ├─ 範例: 失敗 5 次 → 帳號鎖定
│  ├─ 範例: 鎖定期間登入 → 顯示鎖定訊息
│  └─ 範例: 30 分鐘後 → 自動解鎖
│
└─ 問題: 忘記密碼流程?(另開 Story)

@authentication @high-priority
Feature: 使用者登入
  作為 電商網站的會員
  我想要 登入系統
  以便 存取個人化的服務

  Background: 測試用戶存在
    Given 系統中存在以下使用者:
      | email              | password    | status  |
      | user@example.com   | Pass1234    | active  |
      | locked@example.com | Pass1234    | locked  |

  @smoke @happy-path
  Scenario: 使用正確帳密成功登入
    Given 我在登入頁面
    When 我輸入帳號 "user@example.com"
    And 我輸入密碼 "Pass1234"
    And 我點擊登入按鈕
    Then 我應該看到會員首頁
    And 頁面標題應該是 "我的帳戶"
    And 頁面應該顯示 "歡迎回來, user@example.com"

  @smoke
  Scenario: 勾選記住我功能
    Given 我在登入頁面
    When 我輸入帳號 "user@example.com"
    And 我輸入密碼 "Pass1234"
    And 我勾選 "記住我"
    And 我點擊登入按鈕
    Then 我應該看到會員首頁
    And 系統應該設定 Cookie "remember_me" 有效期為 30 天

  @validation
  Scenario Outline: 帳密驗證錯誤
    Given 我在登入頁面
    When 我輸入帳號 "<email>"
    And 我輸入密碼 "<password>"
    And 我點擊登入按鈕
    Then 我應該看到錯誤訊息 "<error_message>"
    And 我應該仍在登入頁面

    Examples: 無效的帳號密碼
      | email              | password | error_message          |
      | invalid@test.com   | Pass1234 | 帳號或密碼錯誤         |
      | user@example.com   | wrong    | 帳號或密碼錯誤         |
      |                    | Pass1234 | 請輸入電子郵件         |
      | user@example.com   |          | 請輸入密碼             |
      | not-an-email       | Pass1234 | 請輸入有效的電子郵件   |

  @security
  Scenario: 連續登入失敗導致帳號鎖定
    Given 我在登入頁面
    When 我使用錯誤密碼嘗試登入 5 次,帳號為 "user@example.com"
    Then 帳號 "user@example.com" 應該被鎖定
    When 我輸入帳號 "user@example.com"
    And 我輸入密碼 "Pass1234"
    And 我點擊登入按鈕
    Then 我應該看到錯誤訊息 "帳號已被鎖定,請 30 分鐘後再試或聯絡客服"

  @security
  Scenario: 鎖定的帳號無法登入
    Given 我在登入頁面
    When 我輸入帳號 "locked@example.com"
    And 我輸入密碼 "Pass1234"
    And 我點擊登入按鈕
    Then 我應該看到錯誤訊息 "帳號已被鎖定,請聯絡客服"

# features/steps/login_steps.py
from behave import given, when, then
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
import time

@given('系統中存在以下使用者:')
def step_impl(context):
    """在資料庫中建立測試用戶"""
    for row in context.table:
        context.test_data.create_user(
            email=row['email'],
            password=row['password'],
            status=row['status']
        )

@given('我在登入頁面')
def step_impl(context):
    context.driver.get(context.base_url + '/login')
    # 等待頁面載入
    WebDriverWait(context.driver, 10).until(
        EC.presence_of_element_located((By.ID, 'email'))
    )

@when('我輸入帳號 "{email}"')
def step_impl(context, email):
    element = context.driver.find_element(By.ID, 'email')
    element.clear()
    element.send_keys(email)

@when('我輸入密碼 "{password}"')
def step_impl(context, password):
    element = context.driver.find_element(By.ID, 'password')
    element.clear()
    element.send_keys(password)

@when('我勾選 "{checkbox_name}"')
def step_impl(context, checkbox_name):
    checkbox = context.driver.find_element(By.ID, 'remember-me')
    if not checkbox.is_selected():
        checkbox.click()

@when('我點擊登入按鈕')
def step_impl(context):
    button = context.driver.find_element(By.ID, 'login-btn')
    button.click()
    # 等待頁面跳轉或錯誤訊息
    time.sleep(1)

@when('我使用錯誤密碼嘗試登入 {count:d} 次,帳號為 "{email}"')
def step_impl(context, count, email):
    for i in range(count):
        context.driver.get(context.base_url + '/login')
        context.driver.find_element(By.ID, 'email').send_keys(email)
        context.driver.find_element(By.ID, 'password').send_keys('WrongPass')
        context.driver.find_element(By.ID, 'login-btn').click()
        time.sleep(0.5)

@then('我應該看到會員首頁')
def step_impl(context):
    WebDriverWait(context.driver, 10).until(
        EC.url_contains('/dashboard')
    )
    assert '/dashboard' in context.driver.current_url

@then('頁面標題應該是 "{title}"')
def step_impl(context, title):
    h1 = context.driver.find_element(By.TAG_NAME, 'h1').text
    assert h1 == title, f"Expected '{title}', but got '{h1}'"

@then('頁面應該顯示 "{text}"')
def step_impl(context, text):
    page_text = context.driver.find_element(By.TAG_NAME, 'body').text
    assert text in page_text, f"Text '{text}' not found on page"

@then('系統應該設定 Cookie "{cookie_name}" 有效期為 {days:d} 天')
def step_impl(context, cookie_name, days):
    cookie = context.driver.get_cookie(cookie_name)
    assert cookie is not None, f"Cookie '{cookie_name}' not found"
    # 驗證 Cookie 有效期(簡化示範)
    assert 'expiry' in cookie

@then('我應該看到錯誤訊息 "{error_message}"')
def step_impl(context, error_message):
    error_element = WebDriverWait(context.driver, 5).until(
        EC.presence_of_element_located((By.CLASS_NAME, 'error-message'))
    )
    assert error_message in error_element.text

@then('我應該仍在登入頁面')
def step_impl(context):
    assert '/login' in context.driver.current_url

@then('帳號 "{email}" 應該被鎖定')
def step_impl(context, email):
    user = context.test_data.get_user(email)
    assert user['status'] == 'locked', f"User {email} is not locked"

作為 網路銀行使用者
我想要 轉帳給其他帳戶
以便 進行金融交易

@banking @transfer @critical
Feature: 銀行轉帳功能
  作為 網路銀行使用者
  我想要 轉帳給其他帳戶
  以便 進行金融交易

  Business Rules:
  - 餘額必須足夠(含手續費)
  - 轉帳限額:單筆最高 50 萬,每日最高 100 萬
  - 轉帳手續費:同行免費,跨行每筆 15 元

  Background: 準備測試帳戶
    Given 系統中存在以下帳戶:
      | account_number | bank_code | balance  | daily_limit |
      | 1234567890     | 001       | 1000000  | 0           |
      | 9876543210     | 001       | 500000   | 0           |
      | 5555555555     | 002       | 0        | 0           |
    And 我已登入帳號 "1234567890"

  @smoke @happy-path
  Scenario: 同行轉帳成功
    Given 我在轉帳頁面
    When 我輸入收款帳號 "9876543210"
    And 我輸入轉帳金額 "10000"
    And 我輸入備註 "還款"
    And 我點擊下一步
    Then 我應該看到轉帳確認頁面
    And 確認頁面應顯示:
      | 項目     | 值           |
      | 收款人   | 9876543210   |
      | 金額     | 10,000       |
      | 手續費   | 0            |
      | 總金額   | 10,000       |
    When 我輸入交易密碼 "123456"
    And 我點擊確認轉帳
    Then 我應該看到 "轉帳成功" 訊息
    And 帳戶 "1234567890" 餘額應該是 "990000"
    And 帳戶 "9876543210" 餘額應該是 "510000"
    And 帳戶 "1234567890" 今日轉帳額度應該是 "10000"

  @happy-path
  Scenario: 跨行轉帳扣除手續費
    Given 我在轉帳頁面
    When 我輸入收款帳號 "5555555555"
    And 我輸入轉帳金額 "5000"
    And 我點擊下一步
    Then 確認頁面應顯示:
      | 項目     | 值           |
      | 收款人   | 5555555555   |
      | 金額     | 5,000        |
      | 手續費   | 15           |
      | 總金額   | 5,015        |
    When 我輸入交易密碼 "123456"
    And 我點擊確認轉帳
    Then 我應該看到 "轉帳成功" 訊息
    And 帳戶 "1234567890" 餘額應該是 "994985"
    And 帳戶 "5555555555" 餘額應該是 "5000"

  @validation @boundary
  Scenario Outline: 轉帳金額驗證
    Given 我在轉帳頁面
    And 帳戶 "1234567890" 餘額為 "<balance>"
    And 帳戶 "1234567890" 今日已轉帳 "<daily_used>"
    When 我輸入收款帳號 "<target>"
    And 我輸入轉帳金額 "<amount>"
    And 我點擊下一步
    Then 我應該看到錯誤訊息 "<error_message>"

    Examples: 無效的轉帳情況
      | balance | daily_used | target     | amount  | error_message          |
      | 10000   | 0          | 9876543210 | 20000   | 餘額不足               |
      | 1000000 | 0          | 9876543210 | 600000  | 超過單筆轉帳限額       |
      | 1000000 | 950000     | 9876543210 | 100000  | 超過每日轉帳限額       |
      | 1000000 | 0          | 5555555555 | 10000   | 餘額不足(含手續費15元) |
      | 1000000 | 0          | 9876543210 | 0       | 金額必須大於0          |
      | 1000000 | 0          | 9876543210 | -100    | 金額必須大於0          |

  @security
  Scenario: 交易密碼錯誤
    Given 我在轉帳頁面
    And 我已填寫轉帳資料並到達確認頁面
    When 我輸入交易密碼 "wrong-password"
    And 我點擊確認轉帳
    Then 我應該看到錯誤訊息 "交易密碼錯誤"
    And 帳戶餘額應保持不變

  @integration
  Scenario: 轉帳後發送簡訊通知
    Given 我在轉帳頁面
    When 我成功轉帳 "10000" 元給帳號 "9876543210"
    Then 系統應該發送簡訊給帳號 "1234567890" 的手機
    And 簡訊內容應包含:
      """
      您已成功轉帳 10,000 元至帳號 9876543210
      餘額: 990,000 元
      """

# features/steps/transfer_steps.py
from behave import given, when, then
from decimal import Decimal

@given('系統中存在以下帳戶:')
def step_impl(context):
    for row in context.table:
        context.bank_system.create_account(
            account_number=row['account_number'],
            bank_code=row['bank_code'],
            balance=Decimal(row['balance']),
            daily_limit=Decimal(row['daily_limit'])
        )

@given('我已登入帳號 "{account}"')
def step_impl(context, account):
    context.current_account = account
    context.bank_system.login(account)

@given('我在轉帳頁面')
def step_impl(context):
    context.transfer_page = context.bank_system.get_transfer_page()

@given('帳戶 "{account}" 餘額為 "{balance}"')
def step_impl(context, account, balance):
    context.bank_system.set_balance(account, Decimal(balance))

@given('帳戶 "{account}" 今日已轉帳 "{amount}"')
def step_impl(context, account, amount):
    context.bank_system.set_daily_used(account, Decimal(amount))

@when('我輸入收款帳號 "{account}"')
def step_impl(context, account):
    context.transfer_page.enter_target_account(account)

@when('我輸入轉帳金額 "{amount}"')
def step_impl(context, amount):
    context.transfer_page.enter_amount(amount)

@when('我輸入備註 "{note}"')
def step_impl(context, note):
    context.transfer_page.enter_note(note)

@when('我點擊下一步')
def step_impl(context):
    context.confirm_page = context.transfer_page.click_next()

@when('我輸入交易密碼 "{password}"')
def step_impl(context, password):
    context.confirm_page.enter_transaction_password(password)

@when('我點擊確認轉帳')
def step_impl(context):
    context.result_page = context.confirm_page.click_confirm()

@when('我成功轉帳 "{amount}" 元給帳號 "{target}"')
def step_impl(context, amount, target):
    context.transfer_page = context.bank_system.get_transfer_page()
    context.transfer_page.enter_target_account(target)
    context.transfer_page.enter_amount(amount)
    context.transfer_page.click_next()
    context.confirm_page.enter_transaction_password('123456')
    context.result_page = context.confirm_page.click_confirm()

@then('我應該看到轉帳確認頁面')
def step_impl(context):
    assert context.confirm_page is not None
    assert context.confirm_page.is_displayed()

@then('確認頁面應顯示:')
def step_impl(context):
    for row in context.table:
        field = row['項目']
        expected_value = row['值']
        actual_value = context.confirm_page.get_field_value(field)
        assert actual_value == expected_value, \
            f"{field}: expected '{expected_value}', got '{actual_value}'"

@then('我應該看到 "{message}" 訊息')
def step_impl(context, message):
    actual_message = context.result_page.get_message()
    assert message in actual_message

@then('帳戶 "{account}" 餘額應該是 "{expected_balance}"')
def step_impl(context, account, expected_balance):
    actual_balance = context.bank_system.get_balance(account)
    expected = Decimal(expected_balance)
    assert actual_balance == expected, \
        f"Account {account}: expected {expected}, got {actual_balance}"

@then('帳戶 "{account}" 今日轉帳額度應該是 "{expected_amount}"')
def step_impl(context, account, expected_amount):
    actual_amount = context.bank_system.get_daily_used(account)
    expected = Decimal(expected_amount)
    assert actual_amount == expected

@then('我應該看到錯誤訊息 "{error_message}"')
def step_impl(context, error_message):
    actual_error = context.transfer_page.get_error_message()
    assert error_message in actual_error

@then('帳戶餘額應保持不變')
def step_impl(context):
    # 驗證餘額未改變
    pass  # 實作餘額檢查邏輯

@then('系統應該發送簡訊給帳號 "{account}" 的手機')
def step_impl(context, account):
    sms_sent = context.bank_system.check_sms_sent(account)
    assert sms_sent, f"No SMS sent to account {account}"

@then('簡訊內容應包含:')
def step_impl(context):
    expected_content = context.text
    actual_content = context.bank_system.get_last_sms_content()
    # 簡化驗證
    assert "轉帳" in actual_content

作為 系統管理員
我想要 執行每日帳務批次處理
以便 計算會員點數與等級

@batch @points-calculation @daily
Feature: 每日點數計算批次
  作為 系統管理員
  我想要 執行每日帳務批次處理
  以便 計算會員點數與等級

  Business Rules:
  - 計算前一日所有交易的點數
  - 點數累積:消費100元=1點,生日當月雙倍
  - 等級:普卡(0-999)、金卡(1000-4999)、白金卡(5000+)

  Background: 準備測試資料
    Given 今天是 "2025-01-15"
    And 系統中存在以下會員:
      | member_id | name | birthday   | current_points | level    |
      | M001      | 張三 | 1990-01-10 | 900            | regular  |
      | M002      | 李四 | 1985-05-20 | 1500           | gold     |
      | M003      | 王五 | 1992-01-05 | 4900           | gold     |

  @happy-path @smoke
  Scenario: 一般消費點數計算
    Given 會員 "M001" 昨日有以下交易:
      | transaction_id | amount | type     |
      | T001           | 15000  | purchase |
      | T002           | 5000   | purchase |
    When 執行每日點數計算批次
    Then 會員 "M001" 的點數應該增加 200
    And 會員 "M001" 的總點數應該是 1100
    And 會員 "M001" 的等級應該是 "gold"

  @business-rule
  Scenario: 生日當月雙倍點數
    Given 會員 "M003" 昨日有以下交易:
      | transaction_id | amount | type     |
      | T003           | 10000  | purchase |
    When 執行每日點數計算批次
    Then 會員 "M003" 的點數應該增加 200
    And 計算明細應該顯示 "生日當月雙倍"
    And 會員 "M003" 的總點數應該是 5100
    And 會員 "M003" 的等級應該從 "gold" 升級為 "platinum"

  @business-rule
  Scenario Outline: 會員等級升級規則
    Given 會員 "<member>" 昨日有以下交易:
      | transaction_id | amount     | type     |
      | T004           | <amount>   | purchase |
    When 執行每日點數計算批次
    Then 會員 "<member>" 的等級應該是 "<expected_level>"

    Examples: 等級變化
      | member | amount | expected_level |
      | M001   | 15000  | gold           |
      | M002   | 250000 | platinum       |
      | M003   | 15000  | platinum       |

  @validation @error-handling
  Scenario: 重複執行批次不重複計算點數
    Given 會員 "M001" 昨日有以下交易:
      | transaction_id | amount | type     |
      | T005           | 10000  | purchase |
    And 每日點數計算批次已執行過一次
    When 執行每日點數計算批次
    Then 批次應該顯示 "今日批次已執行,略過"
    And 會員 "M001" 的點數應該維持不變

  @error-handling
  Scenario: 批次執行錯誤告警
    Given 資料庫連線發生錯誤
    When 執行每日點數計算批次
    Then 批次應該失敗
    And 系統應該記錄錯誤日誌 "資料庫連線失敗"
    And 系統應該發送告警郵件給 "admin@example.com"

  @reporting
  Scenario: 批次執行報告
    Given 會員 "M001", "M002", "M003" 昨日都有交易
    When 執行每日點數計算批次
    Then 批次報告應該包含:
      | 項目           | 值 |
      | 處理會員數     | 3  |
      | 成功計算筆數   | 3  |
      | 失敗筆數       | 0  |
      | 等級升級人數   | 1  |
      | 執行時間       | <2秒 |

# features/steps/batch_steps.py
from behave import given, when, then
from datetime import datetime, timedelta
from decimal import Decimal

@given('今天是 "{date}"')
def step_impl(context, date):
    context.current_date = datetime.strptime(date, '%Y-%m-%d')
    context.batch_system.set_current_date(context.current_date)

@given('系統中存在以下會員:')
def step_impl(context):
    for row in context.table:
        context.batch_system.create_member(
            member_id=row['member_id'],
            name=row['name'],
            birthday=datetime.strptime(row['birthday'], '%Y-%m-%d'),
            current_points=int(row['current_points']),
            level=row['level']
        )

@given('會員 "{member_id}" 昨日有以下交易:')
def step_impl(context, member_id):
    yesterday = context.current_date - timedelta(days=1)
    for row in context.table:
        context.batch_system.create_transaction(
            transaction_id=row['transaction_id'],
            member_id=member_id,
            amount=Decimal(row['amount']),
            trans_type=row['type'],
            trans_date=yesterday
        )

@given('每日點數計算批次已執行過一次')
def step_impl(context):
    context.batch_system.run_daily_points_calculation()
    context.first_run_completed = True

@given('資料庫連線發生錯誤')
def step_impl(context):
    context.batch_system.simulate_db_error()

@when('執行每日點數計算批次')
def step_impl(context):
    context.batch_result = context.batch_system.run_daily_points_calculation()

@then('會員 "{member_id}" 的點數應該增加 {points:d}')
def step_impl(context, member_id, points):
    actual_increase = context.batch_system.get_points_increase(member_id)
    assert actual_increase == points, \
        f"Expected {points} points, but got {actual_increase}"

@then('會員 "{member_id}" 的總點數應該是 {total:d}')
def step_impl(context, member_id, total):
    actual_total = context.batch_system.get_member_points(member_id)
    assert actual_total == total, \
        f"Expected {total} total points, but got {actual_total}"

@then('會員 "{member_id}" 的等級應該是 "{level}"')
def step_impl(context, member_id, level):
    actual_level = context.batch_system.get_member_level(member_id)
    assert actual_level == level, \
        f"Expected level '{level}', but got '{actual_level}'"

@then('會員 "{member_id}" 的等級應該從 "{old_level}" 升級為 "{new_level}"')
def step_impl(context, member_id, old_level, new_level):
    upgrade_log = context.batch_system.get_upgrade_log(member_id)
    assert upgrade_log['from_level'] == old_level
    assert upgrade_log['to_level'] == new_level

@then('計算明細應該顯示 "{note}"')
def step_impl(context, note):
    details = context.batch_result.get_calculation_details()
    assert note in details

@then('批次應該顯示 "{message}"')
def step_impl(context, message):
    assert context.batch_result.message == message

@then('會員 "{member_id}" 的點數應該維持不變')
def step_impl(context, member_id):
    points_before = context.batch_system.get_member_points_before_batch(member_id)
    points_after = context.batch_system.get_member_points(member_id)
    assert points_before == points_after

@then('批次應該失敗')
def step_impl(context):
    assert context.batch_result.status == 'failed'

@then('系統應該記錄錯誤日誌 "{log_message}"')
def step_impl(context, log_message):
    error_logs = context.batch_system.get_error_logs()
    assert any(log_message in log for log in error_logs)

@then('系統應該發送告警郵件給 "{email}"')
def step_impl(context, email):
    sent_emails = context.batch_system.get_sent_emails()
    assert any(email in mail['to'] for mail in sent_emails)

@then('批次報告應該包含:')
def step_impl(context):
    report = context.batch_result.get_report()
    for row in context.table:
        field = row['項目']
        expected_value = row['值']
        actual_value = str(report[field])
        
        if '<' in expected_value:
            # 處理 "<2秒" 這種情況
            threshold = int(expected_value.replace('<', '').replace('秒', ''))
            actual_seconds = int(actual_value.replace('秒', ''))
            assert actual_seconds < threshold
        else:
            assert actual_value == expected_value

作為 第三方應用開發者
我想要 透過 RESTful API 查詢與建立訂單
以便 整合我的應用系統

@api @orders @rest
Feature: 訂單 API
  作為 第三方應用開發者
  我想要 透過 RESTful API 查詢與建立訂單
  以便 整合我的應用系統

  Background: API 認證
    Given 我有有效的 API Token
    And API Base URL 是 "https://api.example.com"

  @smoke @get
  Scenario: 查詢存在的訂單
    Given 系統中存在訂單 "ORD-001",資料如下:
      | customer_name | amount | status  |
      | 張三          | 15000  | pending |
    When 我發送 GET 請求到 "/api/orders/ORD-001"
    Then HTTP 狀態碼應該是 200
    And 回應 JSON 應該包含:
      """
      {
        "order_id": "ORD-001",
        "customer_name": "張三",
        "amount": 15000,
        "status": "pending"
      }
      """

  @validation @get
  Scenario: 查詢不存在的訂單
    When 我發送 GET 請求到 "/api/orders/INVALID"
    Then HTTP 狀態碼應該是 404
    And 回應 JSON 應該包含:
      """
      {
        "error": "Order not found",
        "message": "訂單 INVALID 不存在"
      }
      """

  @smoke @post
  Scenario: 成功建立訂單
    When 我發送 POST 請求到 "/api/orders",內容為:
      """
      {
        "customer_name": "李四",
        "items": [
          {"product_id": "P001", "quantity": 2, "price": 500},
          {"product_id": "P002", "quantity": 1, "price": 1000}
        ],
        "shipping_address": "台北市信義區"
      }
      """
    Then HTTP 狀態碼應該是 201
    And 回應應該包含 Header "Location"
    And 回應 JSON 的 "order_id" 應該不為空
    And 回應 JSON 的 "amount" 應該是 2000
    And 回應 JSON 的 "status" 應該是 "pending"

  @validation @post
  Scenario Outline: 建立訂單時的欄位驗證
    When 我發送 POST 請求到 "/api/orders",內容為:
      """
      <request_body>
      """
    Then HTTP 狀態碼應該是 <status_code>
    And 回應 JSON 的 "error" 應該是 "<error_message>"

    Examples: 無效的訂單資料
      | request_body                                          | status_code | error_message          |
      | {}                                                    | 400         | customer_name is required |
      | {"customer_name": ""}                                 | 400         | customer_name cannot be empty |
      | {"customer_name": "王五", "items": []}                | 400         | items cannot be empty  |
      | {"customer_name": "趙六", "items": [{"product_id": "P001", "quantity": 0}]} | 400 | quantity must be positive |

  @put @business-rule
  Scenario: 取消訂單
    Given 系統中存在訂單 "ORD-002",狀態為 "pending"
    When 我發送 PUT 請求到 "/api/orders/ORD-002/cancel"
    Then HTTP 狀態碼應該是 200
    And 回應 JSON 的 "status" 應該是 "cancelled"
    And 訂單 "ORD-002" 在資料庫中的狀態應該是 "cancelled"

  @validation @business-rule
  Scenario: 無法取消已完成的訂單
    Given 系統中存在訂單 "ORD-003",狀態為 "completed"
    When 我發送 PUT 請求到 "/api/orders/ORD-003/cancel"
    Then HTTP 狀態碼應該是 400
    And 回應 JSON 應該包含:
      """
      {
        "error": "Cannot cancel order",
        "message": "訂單已完成,無法取消"
      }
      """

  @security @authentication
  Scenario: 沒有 Token 無法存取 API
    Given 我沒有 API Token
    When 我發送 GET 請求到 "/api/orders/ORD-001"
    Then HTTP 狀態碼應該是 401
    And 回應 JSON 的 "error" 應該是 "Unauthorized"

  @security @authentication
  Scenario: 無效的 Token 無法存取 API
    Given 我有無效的 API Token
    When 我發送 GET 請求到 "/api/orders/ORD-001"
    Then HTTP 狀態碼應該是 401
    And 回應 JSON 的 "error" 應該是 "Invalid token"

# features/steps/api_steps.py
from behave import given, when, then
import requests
import json

@given('我有有效的 API Token')
def step_impl(context):
    context.api_token = "valid-test-token-12345"
    context.headers = {
        'Authorization': f'Bearer {context.api_token}',
        'Content-Type': 'application/json'
    }

@given('我沒有 API Token')
def step_impl(context):
    context.headers = {
        'Content-Type': 'application/json'
    }

@given('我有無效的 API Token')
def step_impl(context):
    context.headers = {
        'Authorization': 'Bearer invalid-token',
        'Content-Type': 'application/json'
    }

@given('API Base URL 是 "{base_url}"')
def step_impl(context, base_url):
    context.base_url = base_url

@given('系統中存在訂單 "{order_id}",資料如下:')
def step_impl(context, order_id):
    order_data = {}
    for row in context.table:
        for key, value in zip(row.headings, row.cells):
            order_data[key] = value
    
    context.api_system.create_order(order_id, order_data)

@given('系統中存在訂單 "{order_id}",狀態為 "{status}"')
def step_impl(context, order_id, status):
    context.api_system.create_order(order_id, {'status': status})

@when('我發送 GET 請求到 "{endpoint}"')
def step_impl(context, endpoint):
    url = context.base_url + endpoint
    context.response = requests.get(url, headers=context.headers)

@when('我發送 POST 請求到 "{endpoint}",內容為:')
def step_impl(context, endpoint):
    url = context.base_url + endpoint
    request_body = json.loads(context.text)
    context.response = requests.post(
        url,
        headers=context.headers,
        json=request_body
    )

@when('我發送 PUT 請求到 "{endpoint}"')
def step_impl(context, endpoint):
    url = context.base_url + endpoint
    context.response = requests.put(url, headers=context.headers)

@then('HTTP 狀態碼應該是 {status_code:d}')
def step_impl(context, status_code):
    assert context.response.status_code == status_code, \
        f"Expected {status_code}, got {context.response.status_code}"

@then('回應 JSON 應該包含:')
def step_impl(context):
    expected_json = json.loads(context.text)
    actual_json = context.response.json()
    
    for key, expected_value in expected_json.items():
        assert key in actual_json, f"Key '{key}' not found in response"
        assert actual_json[key] == expected_value, \
            f"{key}: expected '{expected_value}', got '{actual_json[key]}'"

@then('回應應該包含 Header "{header_name}"')
def step_impl(context, header_name):
    assert header_name in context.response.headers, \
        f"Header '{header_name}' not found"

@then('回應 JSON 的 "{field}" 應該不為空')
def step_impl(context, field):
    actual_json = context.response.json()
    assert field in actual_json
    assert actual_json[field] is not None
    assert actual_json[field] != ""

@then('回應 JSON 的 "{field}" 應該是 {value:d}')
def step_impl(context, field, value):
    actual_json = context.response.json()
    assert actual_json[field] == value

@then('回應 JSON 的 "{field}" 應該是 "{value}"')
def step_impl(context, field, value):
    actual_json = context.response.json()
    assert actual_json[field] == value

@then('訂單 "{order_id}" 在資料庫中的狀態應該是 "{status}"')
def step_impl(context, order_id, status):
    actual_status = context.api_system.get_order_status(order_id)
    assert actual_status == status

Scenario: 查詢訂單
  Given 我已登入系統
  And 我在訂單列表頁面
  When 我輸入訂單編號 "ORD-001"
  Then 我應該看到訂單詳情

Scenario: 取消訂單
  Given 我已登入系統
  And 我在訂單列表頁面
  When 我點擊取消訂單 "ORD-001"
  Then 訂單應該被取消

Background:
  Given 我已登入系統
  And 我在訂單列表頁面

Scenario: 查詢訂單
  When 我輸入訂單編號 "ORD-001"
  Then 我應該看到訂單詳情

Scenario: 取消訂單
  When 我點擊取消訂單 "ORD-001"
  Then 訂單應該被取消

Scenario: 轉帳金額為0
  When 我輸入轉帳金額 "0"
  Then 我應該看到錯誤訊息 "金額必須大於0"

Scenario: 轉帳金額為負數
  When 我輸入轉帳金額 "-100"
  Then 我應該看到錯誤訊息 "金額必須大於0"

Scenario: 轉帳金額超過限額
  When 我輸入轉帳金額 "1000000"
  Then 我應該看到錯誤訊息 "超過單筆轉帳限額"

Scenario Outline: 轉帳金額驗證
  When 我輸入轉帳金額 "<amount>"
  Then 我應該看到錯誤訊息 "<error>"

  Examples:
    | amount  | error            |
    | 0       | 金額必須大於0    |
    | -100    | 金額必須大於0    |
    | 1000000 | 超過單筆轉帳限額 |

Feature: 會員管理
  Scenario: 註冊會員
  Scenario: 會員登入
  Scenario: 修改會員資料
  Scenario: 會員點數累積
  Scenario: 會員等級升級
  Scenario: 會員優惠券發放
  ... (共 20 個 Scenarios)

# member_registration.feature
Feature: 會員註冊
  Scenario: 註冊會員

# member_authentication.feature
Feature: 會員認證
  Scenario: 會員登入
  Scenario: 會員登出

# member_profile.feature
Feature: 會員資料管理
  Scenario: 修改會員資料

# member_loyalty.feature
Feature: 會員忠誠度計畫
  Scenario: 會員點數累積
  Scenario: 會員等級升級
  Scenario: 會員優惠券發放

When 我在 "username" 欄位輸入 "user@example.com"
And 我在 "password" 欄位輸入 "Pass1234"
And 我點擊 id 為 "login-btn" 的按鈕
Then HTTP 回應碼應該是 200
And Session Cookie 應該包含 "user_id"

When 我輸入帳號 "user@example.com"
And 我輸入密碼 "Pass1234"
And 我點擊登入按鈕
Then 我應該成功登入
And 系統應該記住我的登入狀態

特徵:
- 沒有正式的需求規格流程
- 測試主要依賴手動執行
- 需求文件與程式碼脫節
- 缺乏跨職能協作

建議:
→ 從小團隊試點開始
→ 選擇簡單功能練習 BDD
→ 建立基本的 Three Amigos 會議

特徵:
- 開始撰寫 Feature Files
- 部分功能有自動化測試
- 團隊成員學習 Gherkin 語法
- 偶爾舉行 Discovery Workshop

建議:
→ 建立 Feature File 撰寫規範
→ 培訓團隊成員 BDD 技能
→ 引入 BDD 工具(Cucumber/Behave)

特徵:
- 正式的 BDD 流程與規範
- 大多數新功能使用 BDD
- Three Amigos 成為常規實踐
- 自動化測試覆蓋率提升

建議:
→ 整合 BDD 到 CI/CD Pipeline
→ 建立 Living Documentation
→ 定期 Review Feature Files 品質

特徵:
- BDD 成為團隊標準實踐
- 測試報告與專案管理工具整合
- 量化追蹤 BDD 效益
- 跨團隊分享最佳實務

建議:
→ 優化 BDD 流程效率
→ 建立 Feature File 重構機制
→ 發展組織專屬的 BDD 模式庫

特徵:
- 持續改善 BDD 實踐
- 主動預防缺陷
- BDD 與 DevOps 深度整合
- 創新實驗新的協作方式

建議:
→ AI 輔助 Feature File 生成
→ 探索 BDD 與 SDD 整合
→ 推廣到其他團隊/部門

## BDD 成熟度評估表

### 一、協作文化(20分)
1. [ ] BA/SA/Dev/QA 定期共同討論需求(5分)
2. [ ] 使用 Example Mapping 或類似技術(5分)
3. [ ] Three Amigos 會議已成為常規實踐(5分)
4. [ ] 團隊成員理解彼此的視角與關切(5分)

### 二、需求規格(20分)
1. [ ] 使用 Gherkin 語法撰寫規格(5分)
2. [ ] Feature Files 由 SA/BA 主導撰寫(5分)
3. [ ] 規格涵蓋 Happy Path 與異常情況(5分)
4. [ ] 規格與利害關係人達成共識(5分)

### 三、自動化測試(20分)
1. [ ] Feature Files 可自動化執行(5分)
2. [ ] 自動化測試覆蓋率 > 70%(5分)
3. [ ] 測試在 CI/CD Pipeline 中執行(5分)
4. [ ] 測試報告清晰易懂(5分)

### 四、流程與工具(20分)
1. [ ] 有明確的 BDD 工作流程(5分)
2. [ ] 使用 BDD 框架(Cucumber/Behave 等)(5分)
3. [ ] Feature Files 納入版本控管(5分)
4. [ ] 測試報告與專案管理工具整合(5分)

### 五、持續改善(20分)
1. [ ] 定期 Review Feature Files 品質(5分)
2. [ ] 有 Feature Files 重構機制(5分)
3. [ ] 追蹤並分析 BDD 效益(5分)
4. [ ] 團隊主動分享 BDD 經驗(5分)

---

**總分**: _____ / 100分

**成熟度等級**:
- 0-20分  → Level 1 (初始階段)
- 21-40分 → Level 2 (探索階段)
- 41-60分 → Level 3 (定義階段)
- 61-80分 → Level 4 (管理階段)
- 81-100分 → Level 5 (優化階段)

# BDD 導入計畫

## 一、專案概況

**專案名稱**: BDD 導入計畫
**負責人**: [姓名]
**期程**: 2025-01-01 ~ 2025-06-30 (6個月)
**目標**: 在[團隊/部門]成功導入 BDD 實踐

## 二、現狀分析

**當前挑戰**:
- 需求文件與實作常有落差
- 測試主要依賴手動執行
- 跨職能溝通不足
- 缺陷發現時間較晚

**BDD 成熟度**: Level 1 (初始階段)

## 三、導入目標

**短期目標**(3個月):
- [ ] 完成 BDD 基礎培訓
- [ ] 試點專案使用 BDD
- [ ] 建立 Three Amigos 會議機制
- [ ] 自動化測試覆蓋率 > 50%

**中期目標**(6個月):
- [ ] BDD 推廣到 2-3 個團隊
- [ ] 整合到 CI/CD Pipeline
- [ ] 自動化測試覆蓋率 > 70%
- [ ] 建立 BDD 規範與模板

**長期目標**(12個月):
- [ ] BDD 成為組織標準實踐
- [ ] 缺陷率降低 30%
- [ ] 需求變更時間縮短 40%
- [ ] 達到 Level 3 成熟度

## 四、導入策略

### 階段一:準備階段(第1-4週)

**活動**:
1. 組建 BDD 推動小組
2. 評估組織成熟度
3. 選擇試點團隊與專案
4. 制定培訓計畫

**產出**:
- BDD 成熟度評估報告
- 試點專案清單
- 培訓教材

**負責人**: [姓名]

### 階段二:學習階段(第5-7週)

**活動**:
1. BDD 基礎培訓(2天)
2. Gherkin 撰寫工作坊(1天)
3. Three Amigos 模擬演練(1天)
4. 工具環境設定

**產出**:
- 培訓完成證明
- 第一批 Feature Files
- 開發環境設定文件

**負責人**: [姓名]

### 階段三:試點階段(第8-15週)

**活動**:
1. 選擇 2-3 個簡單功能
2. 舉行 Discovery Workshop
3. 撰寫 Feature Files
4. 實作 Step Definitions
5. 執行自動化測試
6. 試點回顧會議

**產出**:
- 試點功能的完整 Feature Files
- 自動化測試程式碼
- 試點回顧報告

**負責人**: [姓名]

### 階段四:推廣階段(第16-23週)

**活動**:
1. 總結試點經驗
2. 建立 BDD 規範與模板
3. 擴大到其他團隊
4. 整合到 CI/CD Pipeline
5. 建立 Living Documentation

**產出**:
- BDD 實施規範
- Feature File 模板庫
- CI/CD 整合文件

**負責人**: [姓名]

### 階段五:優化階段(第24週起)

**活動**:
1. 收集回饋與改善
2. 追蹤效益指標
3. 定期 Review 與重構
4. 經驗分享與推廣

**產出**:
- 效益追蹤報告
- 最佳實務文件

**負責人**: [姓名]

## 五、資源需求

**人力**:
- BDD 教練:1人(外部顧問或內部專家)
- 試點團隊:8-10人(BA/SA/Dev/QA)
- 推動小組:3-5人

**工具**:
- BDD 框架:Behave/Cucumber(開源)
- CI/CD 工具:Jenkins/GitLab CI(既有)
- 協作工具:Miro/Mural(訂閱制)

**預算**:
- 外部培訓:$50,000
- 工具訂閱:$10,000
- 其他:$20,000
- **總計**:$80,000

## 六、風險管理

| 風險 | 可能性 | 影響 | 應對措施 |
|------|-------|------|----------|
| 團隊成員抗拒改變 | 中 | 高 | 充分溝通,展示價值,從小處開始 |
| 學習曲線陡峭 | 中 | 中 | 提供充足培訓,設立教練輔導 |
| 初期速度變慢 | 高 | 中 | 設定合理期望,持續改善流程 |
| 工具技術問題 | 低 | 中 | 選擇成熟工具,建立技術支援 |
| 管理層支持不足 | 低 | 高 | 定期報告進度,展示量化效益 |

## 七、成功指標

**流程指標**:
- Three Amigos 會議舉辦次數
- Feature Files 撰寫數量
- 自動化測試覆蓋率

**品質指標**:
- 缺陷率變化
- 缺陷發現階段分佈
- 需求變更次數

**效率指標**:
- 需求澄清時間
- 測試執行時間
- 上線後缺陷數

**團隊指標**:
- 團隊滿意度調查
- 跨職能協作評分

## 八、溝通計畫

**利害關係人**:
- 高階主管:月度報告
- 專案經理:雙週報告
- 團隊成員:每日 Standup
- 其他團隊:季度分享會

## 九、附錄

- [附錄A] BDD 成熟度評估結果
- [附錄B] 培訓教材大綱
- [附錄C] Feature File 範本
- [附錄D] 工具安裝指南

常見抱怨:
"撰寫 Feature Files 太花時間了"
"我們連程式都寫不完了,哪有時間寫規格"

根本原因:
- 誤解 BDD 的目的(不只是自動化測試)
- 初期學習曲線
- 流程尚未優化

解決方案:
✅ 溝通 BDD 長期效益(減少返工、降低缺陷)
✅ 從小處開始,累積經驗
✅ 提供充足培訓與輔導
✅ 優化流程,減少不必要的步驟
✅ 展示成功案例的時間節省

數據支持:
"初期可能慢 20%,但 3 個月後速度恢復,
 且缺陷率降低 40%,長期看反而更快"

常見抱怨:
"寫測試不是 QA 的工作嗎?"
"我只負責寫程式碼"

根本原因:
- 角色職責不清
- 缺乏測試文化
- 沒有看到測試的價值

解決方案:
✅ 釐清 BDD 中各角色的責任
   - SA:撰寫 Feature Files
   - Dev:實作 Step Definitions 與功能
   - QA:補充測試場景,執行測試
✅ 強調 Step Definitions 是"可執行的規格"
✅ 建立測試先行文化
✅ 管理層支持與激勵機制

實踐技巧:
"Pair Programming:Dev 與 QA 一起實作測試"
"Code Review:檢查測試覆蓋度"
"CI/CD:測試不通過無法合併"

常見抱怨:
"BA 總是忙著開會,約不到時間"
"利害關係人不想參與技術討論"

根本原因:
- 誤以為 BDD 是技術活動
- 沒有展示參與的價值
- 會議效率低落

解決方案:
✅ 強調 Discovery 是避免做錯需求的關鍵
✅ 控制會議時間(Example Mapping 25分鐘)
✅ 提前準備,高效討論
✅ 展示減少返工的效益
✅ 管理層支持與優先級調整

溝通話術:
"花 30 分鐘討論,可以避免 2 週的返工"
"這不是技術討論,是確保我們做對的事情"

常見問題:
"程式改了,但 Feature File 沒更新"
"Feature File 變成過時的文件"

根本原因:
- 沒有將 Feature Files 視為產品程式碼
- 缺乏自動化執行機制
- Review 流程未涵蓋 Feature Files

解決方案:
✅ 強制規定:程式碼與 Feature Files 一起修改
✅ CI/CD 執行 BDD 測試,失敗不能合併
✅ Code Review 包含 Feature Files
✅ 定期重構與更新
✅ 使用標籤標記過時場景(@deprecated)

流程改善:
PR Checklist:
□ 程式碼修改
□ Feature Files 更新
□ Step Definitions 更新
□ 測試通過

常見抱怨:
"Cucumber/Behave 太複雜了"
"環境設定就花了一整天"

根本原因:
- 缺乏培訓
- 文件不完整
- 工具選擇不當

解決方案:
✅ 提供完整的安裝與設定文件
✅ 準備開箱即用的專案模板
✅ 舉辦工作坊,實作演練
✅ 建立內部技術支援機制
✅ 選擇團隊熟悉技術棧的工具

實踐建議:
"建立 Starter Kit:包含範例專案、文件、教學影片"
"Pair Programming:資深成員帶領新手"
"內部 Q&A 平台:Stack Overflow for BDD"

行動項目:
✅ 建立業務術語詞彙表
✅ 統一 Gherkin 語法風格
✅ 使用具體範例溝通
✅ 避免技術行話

實踐:
每週術語 Review 會議
Feature Files 成為唯一真相來源
新進人員培訓時強調業務語言

傳統文化:
BA 寫需求 → Dev 寫程式 → QA 測試

BDD 文化:
所有人共同對品質負責
- BA/SA:需求正確性
- Dev:實作正確性
- QA:測試完整性
- 大家:最終產品品質

實踐:
Three Amigos 共同決策
Feature Files 所有人都能修改
團隊獎勵機制(非個人)

## 高階主管支持 Checklist

### 1. 理解並認同 BDD 價值
- [ ] 參加 BDD 簡報或工作坊
- [ ] 理解 BDD 不只是測試工具
- [ ] 認同協作優先於工具

### 2. 提供資源與授權
- [ ] 批准培訓預算
- [ ] 允許團隊嘗試新流程
- [ ] 給予學習時間(初期速度可能變慢)

### 3. 建立期望與獎勵
- [ ] 將 BDD 實踐納入績效評估
- [ ] 公開表揚 BDD 成功案例
- [ ] 鼓勵跨職能協作

### 4. 移除障礙
- [ ] 協調資源衝突
- [ ] 處理組織阻力
- [ ] 支持流程調整

### 5. 以身作則
- [ ] 參與重要的 Discovery Workshop
- [ ] 詢問團隊 Feature Files 狀況
- [ ] 關注 BDD 效益指標

❌ 錯誤做法:
"我們要在所有專案導入 BDD!"
"下週開始全部功能都要寫 Feature Files!"

✅ 正確做法:
"選擇 1-2 個小團隊試點"
"從簡單功能開始,累積經驗"
"成功後再逐步擴大"

案例:
某銀行從一個 8 人的團隊開始試點,
用 3 個月時間在一個小功能上實踐 BDD,
成功後再推廣到其他 5 個團隊。

培訓計畫:
□ 入門培訓(2天):BDD 基礎、Gherkin 語法
□ 實戰工作坊(1天):撰寫 Feature Files
□ 技術培訓(1天):工具與自動化
□ 進階工作坊(半天):重構與最佳實務

輔導機制:
- 指派 BDD Coach
- Pair Programming/Writing
- 定期 Office Hours
- 內部技術社群

追蹤指標:

【品質指標】
- 缺陷率變化
- 缺陷發現階段(前移比例)
- 生產缺陷數量

【效率指標】
- 需求澄清時間
- 測試執行時間
- 需求變更次數與影響範圍

【協作指標】
- Three Amigos 會議頻率
- 跨職能溝通滿意度
- Feature Files 協作編輯次數

【技術指標】
- 自動化測試覆蓋率
- Feature Files 數量與品質
- CI/CD 執行時間

展示方式:
→ 月度儀表板
→ 季度回顧簡報
→ 成功案例分享

里程碑慶祝:
✨ 第一個 Feature File 完成
✨ 第一個自動化測試通過
✨ 第一次成功的 Three Amigos 會議
✨ 試點專案完成
✨ 自動化覆蓋率達標

方式:
- 團隊聚餐
- 公開表揚
- 分享會
- 獎勵機制

需求:會員點數兌換功能
- 會員可使用點數兌換商品
- 100 點 = 1 元折抵
- 單筆訂單最多折抵 30%
- 兌換後點數立即扣除
- 點數不足時顯示錯誤

請根據以下需求,撰寫 BDD Feature File:

需求:會員點數兌換功能
- 會員可使用點數兌換商品
- 100 點 = 1 元折抵
- 單筆訂單最多折抵 30%
- 兌換後點數立即扣除
- 點數不足時顯示錯誤

請使用 Gherkin 語法,包含:
1. Feature 描述(含業務價值)
2. Background(如需要)
3. Happy Path Scenario
4. 異常情況 Scenarios
5. 邊界條件測試
6. 使用繁體中文

@loyalty @points-redemption
Feature: 會員點數兌換
  作為 會員
  我想要 使用點數兌換商品
  以便 節省購物支出

  Business Rules:
  - 100 點 = 1 元折抵
  - 單筆訂單最多折抵 30%
  - 兌換後點數立即扣除

  Background:
    Given 會員 "M001" 擁有 5000 點
    And 購物車中有商品,總金額為 1000 元

  @happy-path
  Scenario: 成功使用點數兌換
    When 會員選擇使用 3000 點兌換
    Then 訂單折抵金額應該是 30 元
    And 實付金額應該是 970 元
    And 會員點數餘額應該是 2000 點

  @business-rule
  Scenario: 折抵金額不超過訂單的 30%
    When 會員選擇使用 50000 點兌換
    Then 訂單最多折抵 300 元
    And 實際使用點數應該是 30000 點
    And 會員點數餘額應該是 0 點(不足則用完)

  @validation
  Scenario: 點數不足無法兌換
    Given 會員 "M001" 擁有 1000 點
    When 會員選擇使用 2000 點兌換
    Then 系統應該顯示錯誤訊息 "點數不足"
    And 點數餘額應保持 1000 點不變

  @boundary
  Scenario Outline: 邊界條件測試
    Given 會員擁有 <points> 點
    And 訂單金額為 <order_amount> 元
    When 會員選擇使用 <redeem_points> 點兌換
    Then 折抵金額應該是 <discount> 元
    And 實付金額應該是 <final_amount> 元

    Examples:
      | points | order_amount | redeem_points | discount | final_amount |
      | 10000  | 1000         | 30000         | 300      | 700          |
      | 100    | 1000         | 100           | 1        | 999          |
      | 0      | 1000         | 0             | 0        | 1000         |

AI 生成後,SA 應該:
✅ 檢查業務規則是否正確
✅ 補充 AI 未考慮到的場景
✅ 調整語言使其更符合團隊風格
✅ 與利害關係人確認
❌ 不要直接使用,必須 Review

請檢查以下 Feature File 的品質,並提供改善建議:

[貼上 Feature File 內容]

請檢查:
1. Gherkin 語法是否正確
2. 是否使用業務語言(避免技術細節)
3. Scenario 是否職責單一
4. 是否有重複的場景
5. 測試覆蓋度是否完整
6. 步驟是否清晰可測試

品質檢查結果:

✅ 語法正確
✅ 使用業務語言

⚠️ 改善建議:

1. Scenario "檢查訂單狀態" 包含多個職責
   建議拆分為:
   - "查詢存在的訂單"
   - "查詢不存在的訂單"

2. 步驟 "我點擊 id 為 'submit-btn' 的按鈕"
   包含技術細節,建議改為:
   "我點擊提交按鈕"

3. 缺少異常處理場景:
   - 網路連線失敗
   - 伺服器錯誤(500)

4. Scenario Outline 可合併:
   "測試無效Email" 與 "測試Email格式"
   可使用 Scenario Outline 合併

核心概念:
使用具體範例(Examples)來描述與驗證系統行為

與 BDD 的關係:
BDD 是實踐 SBE 的一種方法
SBE 強調用範例溝通需求
BDD 提供具體的實踐框架(Three Amigos, Gherkin)

## User Story: 計算運費

**規則**: 訂單滿 1000 元免運費,未滿收 80 元運費

**關鍵範例**:
- 訂單 999 元 → 運費 80 元 → 總計 1079 元
- 訂單 1000 元 → 運費 0 元 → 總計 1000 元
- 訂單 1001 元 → 運費 0 元 → 總計 1001 元

**問題**:
- 1000 元是否包含運費前還是運費後?
  → 確認:運費前金額
- 偏遠地區是否不同?
  → 確認:另開 Story

Feature: 計算運費

  Business Rule: 訂單滿 1000 元免運費,未滿收 80 元

  Scenario Outline: 根據訂單金額計算運費
    Given 訂單金額為 <order_amount> 元
    When 系統計算運費
    Then 運費應該是 <shipping_fee> 元
    And 訂單總計應該是 <total> 元

    Examples: 關鍵範例
      | order_amount | shipping_fee | total |
      | 999          | 80           | 1079  |
      | 1000         | 0            | 1000  |
      | 1001         | 0            | 1001  |
      | 500          | 80           | 580   |
      | 2000         | 0            | 2000  |

@when('系統計算運費')
def step_impl(context):
    order_amount = context.order_amount
    context.shipping_fee = calculate_shipping_fee(order_amount)
    context.total = order_amount + context.shipping_fee

def calculate_shipping_fee(order_amount):
    FREE_SHIPPING_THRESHOLD = 1000
    SHIPPING_FEE = 80
    
    if order_amount >= FREE_SHIPPING_THRESHOLD:
        return 0
    else:
        return SHIPPING_FEE

End-to-End BDD:
✅ 優點:測試真實使用者流程
❌ 缺點:慢、脆弱、難維護

Contract BDD:
✅ 優點:快速、穩定、獨立
❌ 缺點:無法測試整合流程

建議:
→ 金字塔策略:多數 Component/Contract,少數 E2E
→ 關鍵流程使用 E2E BDD
→ 服務間互動使用 Contract BDD

問題:
多個服務各有自己的資料庫
測試資料準備複雜

解決方案:
1. Test Data Builders
2. Shared Test Database
3. Service Virtualization
4. Database Seeding Scripts

@contract @payment-service
Feature: 支付服務契約
  
  Scenario: 訂單服務呼叫支付服務處理付款
    Given 支付服務已啟動
    And 支付服務期望收到以下請求:
      """
      POST /api/payments
      {
        "order_id": "ORD-001",
        "amount": 1000,
        "currency": "TWD"
      }
      """
    When 訂單服務發送付款請求
    Then 支付服務應該回應:
      """
      {
        "payment_id": "PAY-001",
        "status": "success"
      }
      """
    And HTTP 狀態碼應該是 200

發展方向:
- AI 自動生成 Feature Files
- AI 建議測試場景
- AI 檢測規格品質
- AI 預測缺陷

影響:
SA 的角色將從"撰寫"轉為"審查與精煉"
更多時間花在業務理解而非文件撰寫

發展方向:
- 視覺化 Gherkin 編輯器
- 拖拉式 Step Definitions
- 自動生成測試程式碼

影響:
降低技術門檻
非技術人員也能參與自動化

發展方向:
- Feature Files 即時預覽
- 與 Wiki/Confluence 整合
- 互動式文件
- 版本追蹤與比較

影響:
文件與程式碼真正同步
利害關係人直接查閱最新規格

Shift-Left Testing:
BDD 前移到需求階段
Discovery Workshop 成為必要流程

Continuous Everything:
- Continuous Discovery
- Continuous Formulation
- Continuous Automation
- Continuous Validation

挑戰:
AI/ML 系統行為不確定性高
傳統 BDD 難以描述機率性行為

新方法:
Given 訓練資料集包含 1000 筆客戶資料
When AI 模型預測客戶流失
Then 準確率應該 >= 85%
And 假陽性率應該 <= 10%

# Feature 層級標籤
@authentication @high-priority
Feature: 使用者登入

  # Scenario 層級標籤
  @smoke @happy-path
  Scenario: 成功登入
  
  @validation @skip
  Scenario: 密碼錯誤

Given 系統中存在以下使用者:
  | name | email            | role  |
  | 張三 | user1@test.com   | admin |
  | 李四 | user2@test.com   | user  |

Given 我建立使用者,資料如下:
  | 姓名   | 張三           |
  | Email  | user@test.com  |
  | 角色   | admin          |

Given 我準備以下 JSON 資料:
  """
  {
    "name": "張三",
    "email": "user@test.com"
  }
  """

Then 系統應該回應:
  """
  註冊成功!
  
  歡迎加入我們的服務。
  """

# features/[module]/[feature_name].feature

@[module] @[priority]
Feature: [功能名稱]
  作為 [使用者角色]
  我想要 [功能描述]
  以便 [業務價值]
  
  # 業務規則說明(可選)
  Business Rules:
  - 規則 1
  - 規則 2
  
  # 相關文件(可選)
  References:
  - User Story: US-XXX
  - Use Case: UC-XXX
  - 業務文件: [連結]

  Background: [共同前置條件描述]
    Given [步驟 1]
    And [步驟 2]

  @smoke @happy-path
  Scenario: [正常情況描述]
    Given [前置條件]
    When [執行動作]
    Then [預期結果]
    And [額外驗證]

  @validation
  Scenario Outline: [驗證場景描述]
    Given [前置條件] "<參數>"
    When [動作] "<參數>"
    Then [結果] "<參數>"
    
    Examples: [資料描述]
      | 參數1 | 參數2 | 預期結果 |
      | 值1   | 值2   | 結果1    |
      | 值3   | 值4   | 結果2    |

  @error-handling
  Scenario: [異常處理描述]
    Given [前置條件]
    When [觸發異常的動作]
    Then [錯誤處理結果]

# Example Mapping: [Story 名稱]

**日期**: YYYY-MM-DD
**參與者**: BA, SA, Dev, QA
**Story ID**: US-XXX
**估計時間**: 25 分鐘

## User Story

## 業務規則與範例

### 📘 規則 1: [規則描述]
- ✅ 範例 1: [具體範例]
- ✅ 範例 2: [具體範例]
- ✅ 範例 3: [具體範例]

### 📘 規則 2: [規則描述]
- ✅ 範例 1: [具體範例]
- ✅ 範例 2: [具體範例]

## ❓ 待釐清問題
1. [問題描述] - 負責人:[姓名] - 期限:[日期]
2. [問題描述] - 負責人:[姓名] - 期限:[日期]

## 🛠 技術考量
- [技術點 1]
- [技術點 2]

## ✅ 決議
- [ ] Story 狀態: ☑ Ready / ⚠ Need Work / 📏 Too Big
- [ ] 後續行動:
  - SA: 撰寫 Feature File - 期限:[日期]
  - Dev: 評估技術方案 - 期限:[日期]
  - QA: 準備測試資料 - 期限:[日期]

## 📎 附件
- Example Map 照片: [連結]
- 相關文件: [連結]

## Discovery Workshop Checklist

### 會前準備
- [ ] 確認 User Story 已撰寫
- [ ] 預約會議室(25分鐘)
- [ ] 準備便利貼與白板/線上工具
- [ ] 通知 Three Amigos 參與
- [ ] 準備 Acceptance Criteria

### 會議進行
- [ ] 快速回顧 User Story
- [ ] 識別業務規則(黃色便利貼)
- [ ] 每個規則提供具體範例(綠色便利貼)
- [ ] 記錄待釐清問題(紅色便利貼)
- [ ] 討論技術考量(藍色便利貼)
- [ ] 決定 Story 是否 Ready

### 會後行動
- [ ] 拍照記錄 Example Map
- [ ] 更新問題到專案管理工具
- [ ] 指派問題負責人與期限
- [ ] SA 撰寫 Feature File

## Feature File 撰寫 Checklist

### Feature 層級
- [ ] Feature 描述清楚,包含"作為...我想要...以便..."
- [ ] Business Rules 明確列出
- [ ] References 連結到相關文件
- [ ] 標籤使用恰當(@module, @priority)

### Background
- [ ] 僅包含真正共用的前置條件
- [ ] 不超過 5 個步驟
- [ ] 避免包含驗證(Then)

### Scenario
- [ ] 標題描述清楚
- [ ] 職責單一
- [ ] 使用業務語言,避免技術細節
- [ ] Given-When-Then 結構正確
- [ ] 步驟數量合理(不超過 10 步)

### Scenario Outline
- [ ] Examples 有描述性名稱
- [ ] 參數名稱清楚
- [ ] 測試資料有代表性

### 覆蓋度
- [ ] 包含 Happy Path
- [ ] 包含主要異常情況
- [ ] 包含邊界條件
- [ ] 包含業務規則驗證

### 標籤
- [ ] @smoke:冒煙測試
- [ ] @happy-path:正常流程
- [ ] @validation:驗證場景
- [ ] @error-handling:異常處理
- [ ] 優先級標籤

## Step Definitions 實作 Checklist

### 程式碼品質
- [ ] 步驟匹配正確
- [ ] 參數提取正確
- [ ] 避免硬編碼
- [ ] 適當使用 Page Object 模式
- [ ] 錯誤訊息清楚

### 測試資料
- [ ] 測試資料準備完整
- [ ] 使用 Background/Hooks 準備環境
- [ ] 測試結束後清理資料
- [ ] 測試資料獨立,可重複執行

### 等待與同步
- [ ] 適當使用顯式等待
- [ ] 避免使用 sleep
- [ ] 處理非同步操作

### 可維護性
- [ ] 共用步驟提取到共用檔案
- [ ] 適當使用輔助函式
- [ ] 程式碼有適當註解
- [ ] 遵循團隊編碼規範

## CI/CD 整合 Checklist

### Pipeline 設定
- [ ] BDD 測試納入 CI Pipeline
- [ ] 測試失敗會阻止部署
- [ ] 並行執行測試(如適用)
- [ ] 設定合理的 timeout

### 環境設定
- [ ] Headless 模式(Web UI)
- [ ] 環境變數設定(URLs, Credentials)
- [ ] 測試資料庫設定
- [ ] Docker 容器化(如適用)

### 報告與通知
- [ ] 產生 HTML/JSON 報告
- [ ] 報告上傳到 Artifacts
- [ ] 失敗時發送通知(Email/Slack)
- [ ] 截圖附加到報告

### 測試選擇
- [ ] Commit: @smoke 測試
- [ ] PR: @smoke + @regression
- [ ] Nightly: 完整測試套件
- [ ] 使用標籤控制執行範圍

## Feature Files 維護 Checklist

### 定期 Review (每季)
- [ ] 檢查過時場景,標記 @deprecated
- [ ] 移除已廢棄功能的 Feature Files
- [ ] 更新業務術語
- [ ] 重構重複場景

### 品質檢查
- [ ] Gherkin 語法正確性
- [ ] 業務語言使用
- [ ] 場景職責單一
- [ ] 測試覆蓋度完整

### 文件同步
- [ ] Feature Files 與程式碼同步
- [ ] Feature Files 與 User Stories 對應
- [ ] 更新相關文件連結
- [ ] 版本控管提交訊息清楚

### 重構機會
- [ ] 提取 Background
- [ ] 合併為 Scenario Outline
- [ ] 拆分大 Feature
- [ ] 消除技術細節

BDD 的核心是"對話",不是"測試"
工具和自動化是輔助,不是目的
投資在建立協作文化上

用具體範例討論需求
避免抽象、模糊的描述
範例是共同理解的基礎

BDD 是一個旅程,不是終點
定期回顧與調整流程
從錯誤中學習
慶祝小成功

沒有一體適用的 BDD
根據團隊與專案調整實踐
靈活應用,不拘泥於形式
關注價值,而非規則

# Feature File 結構
@tag1 @tag2
Feature: 功能名稱
  作為 [角色]
  我想要 [功能]
  以便 [價值]

  Background:
    Given 共用前置條件

  @scenario-tag
  Scenario: 場景名稱
    Given 前置條件
    When 執行動作
    Then 預期結果
    And 額外步驟
    But 對比步驟

  Scenario Outline: 參數化場景
    Given 我有 <param1>
    When 我執行 <param2>
    Then 結果是 <result>
    
    Examples:
      | param1 | param2 | result |
      | 值1    | 值2    | 結果1  |

  # 資料表格
  Given 資料如下:
    | 欄位1 | 欄位2 |
    | 值1   | 值2   |

  # 多行文字
  Given JSON 資料:
    """
    { "key": "value" }
    """

會議時間: 25 分鐘
參與者: BA/SA, Dev, QA

流程:
1. Review User Story (2分鐘)
2. 識別業務規則 (5分鐘)
3. 提供具體範例 (10分鐘)
4. 記錄問題 (5分鐘)
5. 決定 Ready? (3分鐘)

產出:
- Example Map
- 問題清單
- Story 狀態

🟨 黃色 = 業務規則
🟩 綠色 = 具體範例
🟥 紅色 = 待釐清問題
🟦 藍色 = 技術考量