「韌性，不只是一套功能能否執行，更在於它能否承受真實世界的挑戰。」

在專案開發中，程式是否能運行只是第一步；真正的挑戰，是如何在 不同情境、不同使用者 手中依然穩定可用。
因此，在 部署完成（Day18） 之後，我們必須進入下一個關鍵階段：測試與調整。

一、工程測試：Debug 是專案的免疫系統

在軟體層面，Debug 不只是「修 bug」，而是一個 品質防線。

測試面向

1. 功能測試 (Function Test)

   • 驗證問卷輸入 → 清單輸出是否正確。
   • API 是否能正確串接資料庫、電商資訊。

2. 壓力測試 (Load Test)

   • 使用工具（如 Apache JMeter、k6）模擬 50–100 個使用者同時提交問卷。
   • 檢視 MongoDB Atlas 與 Vercel 是否能撐住高峰。

3. 回歸測試 (Regression Test)

   • 每次修改後，檢查舊功能是否正常運行。
   • 避免「修了一個洞，卻破了另一個口袋」。

技術方案

• Jest / Cypress 進行單元測試與 E2E 測試。
• GitHub Actions 串接 CI/CD pipeline，自動化檢查。

二、使用者測試：Usability Test 才是核心考驗

如果 Debug 是「免疫系統」，那 Usability Test（易用性測試） 就是「體檢報告」。

在防災平台中，最重要的問題不是「系統跑不跑得動」，而是：
「大眾使用者，能否在 3 分鐘內順利完成清單？」

測試方法

1. 任務導向測試 (Task-based Test)

   • 任務示例：「幫一個四口之家＋一隻狗生成避難清單」。
   • 限定操作時間：3 分鐘內完成。

2. 觀察法 (Observation)

   • 測試族群：單身上班族、家庭主婦、銀髮族、飼主。
   • 紀錄他們的表情、遲疑、錯誤操作。

3. 回饋收集 (Feedback)

   • 測試後進行簡單訪談：「哪裡最容易？哪裡最困難？」
   • 發放簡短問卷（SUS 系統可用性量表，1–5 分）。

測試指標 (KPI)

• 完成率 (Completion Rate)：多少人能完整完成流程？
• 操作時間 (Time on Task)：是否 ≤ 3 分鐘？
• 錯誤率 (Error Rate)：使用者點錯、返回次數。
• 主觀滿意度 (SUS Score)：1–5 分量表，評估使用者體驗。

三、實際執行步驟

1. 工程測試（Debug）

• [ ] 建立測試帳號與測試資料庫（MongoDB Atlas 測試環境）。
• [ ] 驗證問卷輸入 → 清單輸出是否正確。
• [ ] 測試 API 回傳，確保不同輸入組合都能正確處理。
• [ ] 使用 JMeter/k6 進行壓力測試，模擬高併發。
• [ ] 每次更新功能後，重新跑回歸測試。

2. 使用者測試（Usability Test）

• [ ] 定義任務：「幫四口之家＋一隻狗生成避難清單」。
• [ ] 招募 5–7 位不同背景的使用者（單身、家庭、長者、飼主）。
• [ ] 讓他們實際操作平台，並全程觀察行為。
• [ ] 測試後進行簡短訪談 + 問卷回饋（SUS Score）。

3. 數據分析與調整

• 完成率：多少人能完成清單？
• 平均操作時間：是否 ≤ 3 分鐘？
• 錯誤率：常見卡關點在哪裡？
• 滿意度：使用者是否覺得操作流暢？

依據結果進行優先排序：

• 高優先：阻止完成任務的問題（如按鈕不明顯）。
• 中優先：造成延誤但仍能完成的問題（如文字艱澀）。
• 低優先：美觀或細節問題。

四、調整迭代：韌性是「持續改善」的過程

測試不是結束，而是 下一輪設計的起點。

• 短期調整：修正阻止完成任務的關鍵問題（表單順序、按鈕顯示）。
• 中期優化：根據數據調整資訊架構，重新分層物資清單。
• 長期迭代：加入更多 AI 情境化建議，提升「陪伴感」。

作為 PM，我要確保這個循環能不斷推進：
測試 → 分析 → 改善 → 再測試。

五、結語：防災平台的真正驗證

程式可以靠工程師 Debug，但「防災平台」的真正驗證，必須交給一般使用者。
唯有確保「任何人」都能在 3 分鐘內順利完成清單，這個專案才算達到 韌性生活指南 的目標。

正如一句老話：
「工具的價值，不在於它有多強大，而在於它是否真的能被人使用。」