跳至主要内容

US-202: 訂單狀態流轉 - 手動測試指南

測試日期: ____________ 測試人員: ____________ 測試環境: npm run dev (localhost:3000)

測試前準備​

1. 啟動開發伺服器​

npm run dev

2. 登入測試帳號​

測試帳號:

角色用戶名密碼
店員staff@florist.comPassword123!
設計師designer@florist.comPassword123!
送貨員delivery@florist.comPassword123!

3. 準備測試訂單​

建議先創建一筆測試訂單（參考 US-201 測試指南）或使用 Mock API 中的種子數據。

訂單狀態流程圖​

待確認 (PENDING)
    ↓
已確認 (CONFIRMED)
    ↓
設計中 (DESIGNING)
    ↓
待出貨 (READY)
    ↓
配送中 (DELIVERING)
    ↓
已完成 (COMPLETED)

測試場景​

✅ Scenario 1: 確認訂單（待確認 → 已確認）​

目標: 驗證店員可以確認訂單

操作步驟​

  1. 創建一筆新訂單（或使用現有的「待確認」訂單）

    • 訪問 http://localhost:3000/orders/new
    • 填寫並提交訂單表單
    • ✅ 驗證: 訂單創建成功，狀態為「待確認」

  2. 進入訂單詳情頁

    • 點擊訂單編號（例如 ABC-20251104-0001）
    • 或直接訪問 http://localhost:3000/orders/{orderId}
    • ✅ 驗證: 看到訂單詳情頁面

  3. 檢查訂單狀態區塊

    • ✅ 驗證: 狀態顯示為「待確認」（PENDING）
    • ✅ 驗證: 狀態進度條顯示在第一步
    • ✅ 驗證: 看到「確認訂單」按鈕

  4. 確認訂單

    • 點擊「確認訂單」按鈕
    • ✅ 驗證: 顯示確認對話框或直接執行
    • ✅ 驗證: 看到成功訊息「訂單已確認」

  5. 驗證狀態變更

    • ✅ 驗證: 訂單狀態變更為「已確認」（CONFIRMED）
    • ✅ 驗證: 狀態進度條移至第二步
    • ✅ 驗證: 「確認訂單」按鈕消失
    • ✅ 驗證: 出現新的操作按鈕（例如「開始設計」）

  6. 檢查狀態歷史

    • 向下滾動至「狀態歷史」區塊
    • ✅ 驗證: 看到狀態變更記錄: 
      [時間] staff@florist.com (店員) 將訂單從「待確認」變更為「已確認」

預期結果​

  • ✅ 訂單狀態成功變更
  • ✅ 狀態歷史記錄正確
  • ✅ 操作按鈕動態顯示

✅ Scenario 2: 設計師開始設計（已確認 → 設計中）​

目標: 驗證設計師可以開始設計

操作步驟​

  1. 確保訂單狀態為「已確認」（完成 Scenario 1）

  2. 切換至設計師帳號

    • 登出店員帳號
    • 使用 designer@florist.com 登入

  3. 進入訂單詳情頁

    • 訪問同一筆訂單
    • ✅ 驗證: 看到「開始設計」按鈕

  4. 開始設計

    • 點擊「開始設計」按鈕
    • ✅ 驗證: 狀態變更為「設計中」（DESIGNING）
    • ✅ 驗證: 狀態進度條移至第三步

  5. 驗證操作按鈕

    • ✅ 驗證: 「開始設計」按鈕消失
    • ✅ 驗證: 出現「完成設計」按鈕

預期結果​

  • ✅ 設計師可以開始設計
  • ✅ 狀態流轉正確

✅ Scenario 3: 設計完成（設計中 → 待出貨）​

目標: 驗證設計師可以完成設計

操作步驟​

  1. 確保訂單狀態為「設計中」（完成 Scenario 2）
  2. 在訂單詳情頁
  3. 點擊「完成設計」按鈕
  4. ✅ 驗證: 狀態變更為「待出貨」（READY）
  5. ✅ 驗證: 狀態進度條移至第四步
  6. ✅ 驗證: 狀態歷史記錄新增一筆「設計中 → 待出貨」

預期結果​

  • ✅ 設計完成流程正常
  • ✅ 狀態流轉正確

✅ Scenario 4: 開始配送（待出貨 → 配送中）​

目標: 驗證送貨員可以開始配送

操作步驟​

  1. 確保訂單狀態為「待出貨」（完成 Scenario 3）

  2. 切換至送貨員帳號

    • 登出設計師帳號
    • 使用 delivery@florist.com 登入

  3. 進入訂單詳情頁

    • ✅ 驗證: 看到「開始配送」按鈕

  4. 開始配送

    • 點擊「開始配送」按鈕
    • ✅ 驗證: 狀態變更為「配送中」（DELIVERING）
    • ✅ 驗證: 狀態進度條移至第五步

  5. 驗證操作按鈕

    • ✅ 驗證: 「開始配送」按鈕消失
    • ✅ 驗證: 出現「完成配送」按鈕

預期結果​

  • ✅ 送貨員可以開始配送
  • ✅ 狀態流轉正確

✅ Scenario 5: 完成配送（配送中 → 已完成）​

目標: 驗證送貨員可以完成配送

操作步驟​

  1. 確保訂單狀態為「配送中」（完成 Scenario 4）
  2. 在訂單詳情頁
  3. 點擊「完成配送」按鈕
  4. ✅ 驗證: 狀態變更為「已完成」（COMPLETED）
  5. ✅ 驗證: 狀態進度條顯示全部完成（綠色勾選）
  6. ✅ 驗證: 所有操作按鈕消失（已完成訂單不可操作）

預期結果​

  • ✅ 配送完成流程正常
  • ✅ 訂單進入完成狀態

✅ Scenario 6: 完整狀態流轉（端到端測試）​

目標: 驗證完整的訂單生命週期

操作步驟​

  1. 店員創建訂單

    • 使用 staff@florist.com 登入
    • 創建新訂單
    • ✅ 驗證: 狀態為「待確認」

  2. 店員確認訂單

    • 點擊「確認訂單」
    • ✅ 驗證: 狀態變更為「已確認」

  3. 設計師開始設計

    • 切換至 designer@florist.com
    • 點擊「開始設計」
    • ✅ 驗證: 狀態變更為「設計中」

  4. 設計師完成設計

    • 點擊「完成設計」
    • ✅ 驗證: 狀態變更為「待出貨」

  5. 送貨員開始配送

    • 切換至 delivery@florist.com
    • 點擊「開始配送」
    • ✅ 驗證: 狀態變更為「配送中」

  6. 送貨員完成配送

    • 點擊「完成配送」
    • ✅ 驗證: 狀態變更為「已完成」

  7. 檢查狀態歷史

    • ✅ 驗證: 狀態歷史記錄完整，包含所有 6 次狀態變更
    • ✅ 驗證: 每筆記錄包含時間、操作者、狀態變更

預期結果​

  • ✅ 完整流程順利完成
  • ✅ 所有狀態流轉正確
  • ✅ 狀態歷史完整記錄

✅ Scenario 7: 權限控制（錯誤場景）​

目標: 驗證角色權限控制

操作步驟​

  1. 創建一筆「設計中」狀態的訂單

  2. 使用送貨員帳號嘗試操作設計師的按鈕

    • 使用 delivery@florist.com 登入
    • 進入訂單詳情頁
    • ✅ 驗證: 不顯示「完成設計」按鈕（設計師專用）
    • ✅ 驗證: 只看到適合送貨員的按鈕（或無按鈕）

  3. 測試 API 層級權限（可選）

    • 打開開發者工具 → Console
    • 嘗試直接調用 API: 
      fetch('/api/v1/orders/{orderId}/status', {
        method: 'PUT',
        headers: {
          'Authorization': `Bearer ${localStorage.getItem('access_token')}`,
          'Content-Type': 'application/json'
        },
        body: JSON.stringify({ newStatus: 'READY' })
      })
    • ✅ 驗證: 返回 403 Forbidden（權限不足）

預期結果​

  • ✅ 按鈕根據角色動態顯示
  • ✅ API 層級權限檢查正常

✅ Scenario 8: 查看狀態歷史時間軸​

目標: 驗證狀態歷史顯示正確

操作步驟​

  1. 使用一筆有多次狀態變更的訂單
  2. 進入訂單詳情頁
  3. 向下滾動至「狀態歷史」區塊
  4. ✅ 驗證: 看到時間軸樣式的歷史記錄（垂直線 + 節點）
  5. ✅ 驗證: 每筆記錄包含:
    • 時間戳（例如：2025-11-04 10:30:00）
    • 狀態變更（例如：待確認 → 已確認）
    • 操作者（例如：staff@florist.com）
    • 操作說明（可選）
  6. ✅ 驗證: 記錄按時間倒序排列（最新在最上方）

預期結果​

  • ✅ 狀態歷史顯示清晰
  • ✅ 時間軸樣式美觀
  • ✅ 資訊完整正確

✅ Scenario 9: 狀態進度條視覺化​

目標: 驗證狀態進度條正確顯示

操作步驟​

  1. 測試不同狀態的訂單:

    • 「待確認」訂單
    • ✅ 驗證: 進度條在第 1 步（待確認高亮）
    • 「已確認」訂單
    • ✅ 驗證: 進度條在第 2 步（已確認高亮）
    • 「設計中」訂單
    • ✅ 驗證: 進度條在第 3 步
    • 「配送中」訂單
    • ✅ 驗證: 進度條在第 5 步
    • 「已完成」訂單
    • ✅ 驗證: 進度條全部完成（綠色）

  2. 驗證進度條樣式

    • ✅ 驗證: 已完成步驟顯示為綠色或勾選
    • ✅ 驗證: 當前步驟高亮顯示
    • ✅ 驗證: 未完成步驟顯示為灰色

預期結果​

  • ✅ 進度條正確反映訂單狀態
  • ✅ 視覺化清晰易懂

✅ Scenario 10: 響應式設計（手機版）​

目標: 驗證手機版狀態流轉功能

操作步驟​

  1. 切換至手機視圖（開發者工具 → 裝置模擬）
  2. 進入訂單詳情頁
  3. ✅ 驗證: 狀態進度條在手機版正常顯示（可能為垂直佈局）
  4. ✅ 驗證: 操作按鈕大小適合觸控（至少 44x44px）
  5. ✅ 驗證: 狀態歷史區塊在手機版可讀
  6. ✅ 驗證: 點擊按鈕可正常變更狀態

預期結果​

  • ✅ 手機版功能正常
  • ✅ UI 適合小螢幕

測試檢查清單​

完成所有測試場景後，請勾選以下項目：

基本功能​

  • Scenario 1: 確認訂單（待確認 → 已確認）
  • Scenario 2: 開始設計（已確認 → 設計中）
  • Scenario 3: 完成設計（設計中 → 待出貨）
  • Scenario 4: 開始配送（待出貨 → 配送中）
  • Scenario 5: 完成配送（配送中 → 已完成）
  • Scenario 6: 完整狀態流轉（端到端）
  • Scenario 7: 權限控制
  • Scenario 8: 狀態歷史時間軸
  • Scenario 9: 狀態進度條
  • Scenario 10: 響應式設計

UI/UX​

  • 狀態進度條清晰易懂
  • 操作按鈕根據角色動態顯示
  • 成功訊息顯示正確
  • 狀態歷史時間軸樣式美觀
  • DaisyUI 語義色彩正確應用

權限與安全​

  • 按鈕根據角色顯示/隱藏
  • API 層級權限檢查正常
  • 無權限操作返回 403 錯誤

API​

  • PUT /api/v1/orders/:id/status 正常運作
  • GET /api/v1/orders/:id/history 正常運作
  • 錯誤響應格式正確
  • 狀態歷史記錄正確

已知問題​

記錄測試過程中發現的問題：

測試結論​

  • 測試通過: ☐ 是 / ☐ 否
  • 備註: ___________________________________________________________
  • 測試人員簽名: ________________ 日期: ________________

最後更新: 2025-12-10