一、功能可以執行，不代表整個系統沒有問題

經過前面的開發，我們已經完成病患資料新增、查詢、修改、刪除、搜尋、詳細資料、表單驗證、登入與介面調整。

但每個功能分開測試成功，不代表把它們連在一起之後也一定正常。

例如，新增資料成功了，病患清單卻沒有顯示；修改資料成功了，詳細頁面仍然出現舊內容；登出後，卻還能直接打開病患清單。

這些都是整合測試需要發現的問題。

二、先確認整個系統的操作流程

我們可以把系統的主要流程整理成以下步驟：

1. 開啟登入頁面。
2. 輸入正確帳號與密碼。
3. 進入病患清單。
4. 新增一筆測試資料。
5. 確認清單中出現新資料。
6. 透過搜尋功能找到該筆資料。
7. 開啟詳細資料頁面。
8. 修改其中一個欄位，確認修改結果。
9. 刪除測試資料，確認清單中不再出現。
10. 登出後，嘗試重新進入病患清單。

完成這一輪，就能初步檢查主要功能是否有串接成功。

三、建立測試案例表

測試時不要只記錄「成功」或「失敗」，還要寫下測試條件與預期結果。

測試項目 測試方式 預期結果
登入 輸入正確帳密 成功進入病患清單
登入失敗 輸入錯誤密碼 顯示錯誤提示
新增資料 填寫合法資料 資料成功寫入資料庫
表單驗證 留空必填欄位 阻止不合法資料送出或寫入
搜尋資料 輸入存在的姓名 顯示符合條件的資料
查詢詳細資料 輸入有效 ID 顯示正確的單筆資料
修改資料 修改電話等欄位 資料庫與畫面顯示更新
刪除資料 刪除測試紀錄 清單不再顯示該筆資料
權限檢查 登出後直接輸入受保護網址 被導回登入頁面
不存在的 ID 查詢不存在的資料 顯示適當提示，不直接洩漏例外

這份表格可以依照實際功能增減。測試結果應記錄真實執行情況，不要因為預期結果正確，就直接將案例標記為通過。

四、除了正常情況，也要測試異常情況

使用者不一定會按照我們預想的方式操作，因此還需要測試邊界情況。

例如：

• 姓名欄位輸入超過限制的文字。
• 電話欄位輸入不符合格式的內容。
• 搜尋一個不存在的姓名。
• 在網址中輸入負數或非數字 ID。
• 直接進入需要登入的網址。
• 資料庫暫時無法連線。
• 連續點擊新增或刪除按鈕。

這些測試可以幫助我們確認系統是否有適當的錯誤處理，而不是只在理想情況下才正常運作。

五、檢查資料庫與畫面是否一致

除了觀察網頁結果，也可以直接在 MySQL 中檢查測試資料。

例如：

SELECT id, name, gender, birth_date, phone
FROM patient
ORDER BY id DESC;

修改資料後，確認資料庫中的值也有改變；刪除資料後，確認測試紀錄是否真的依照預期處理。

注意，測試刪除功能時只應使用自己建立的測試資料。真實醫療紀錄不能因為測試而任意刪除。

六、記錄測試結果與修正內容

如果測試失敗，可以依照以下順序排查：

1. 瀏覽器是否顯示正確的網址與參數？
2. Servlet 是否有收到表單資料？
3. SQL 是否正確執行？
4. MySQL 中的資料是否真的改變？
5. JSP 是否讀取正確的 attribute？
6. 是否因為登入狀態或權限檢查而被導向其他頁面？

將錯誤的現象、原因與修正方式記錄下來，不只能幫助自己除錯，也能成為專題成果的一部分。

七、今日小結

今天將前面完成的功能串成一條完整流程，並透過測試案例檢查正常操作與異常情況。

整合測試的目的，不只是證明程式能執行，更是確認不同功能之間能否正確合作。

下一篇就是整個系列的最後一天。我們將回顧這 30 天完成的成果，整理目前的限制，以及未來還可以如何擴充系統。