產品頁與價格
- 開簡單商品與可變商品各一個，檢查售價、特價、庫存狀態、圖片與選項。
- 加入購物車，確認項目、數量與價格正確。
通過：購物車顯示正確商品。
WooCommerce 更新後回歸測試：由產品頁到訂單狀態的實戰清單
WooCommerce 更新完成、外掛列表全部顯示已更新，不代表網店可以如常收單。前台首頁可能載入，但購物車、結帳、稅額、付款 Webhook 或訂單電郵其中一段失效；團隊看到「網站開得到」，就過早宣佈完成。
這篇把更新後的回歸測試拆成一條可重複的路徑：先確認更新與資料庫狀態，再用一張受控測試訂單走完產品頁、購物車、結帳、付款、訂單狀態與背景工作。每一步都要有可核對的證據。這不是固定的 30 分鐘流程，也不是服務承諾；實際時間取決於產品選項、稅運規則、付款方式與外掛數量。
先看邊界
這是更新後測試，不是 staging 隔離教學
若你尚未更新，先在 staging 隔離付款、電郵、Webhook 與高風險排程；可先讀 WooCommerce 更新前的暫存站隔離清單。本篇假設更新已套用，要驗的是更新後能否安全收單。
先把「更新完成」定義清楚
編輯建議：不要把「Dashboard 沒有紅色提示」當成唯一完成條件。先後台、再前台，順序錯了會把版本問題誤判成佈景主題或快取問題。
| 檢查位置 | 要看甚麼 | 未完成時 |
|---|---|---|
| WordPress 的更新頁 | 核心、外掛、佈景主題沒有未完成項目；例外項目有記錄 | 先完成或記錄例外，不要假設已更新 |
| WooCommerce 狀態 | WooCommerce 版本與資料庫狀態；有沒有 database update notice | 依官方提示完成資料庫更新；先備份資料庫 [1][3] |
| PHP／伺服器日誌 | 更新後沒有新的 fatal error 或重複警告 | 先處理錯誤，再開始前台測試 |
WooCommerce 官方更新指引明確說，若外掛檔案更新後出現資料庫更新提示，應先完成資料庫更新，才繼續測試商店 [1]。System Tools 文件亦提醒，執行 WooCommerce 資料庫更新前一定要備份資料庫 [3]。編輯建議：若資料庫更新未完成，先不要用前台測試結果判斷更新成敗；版本不一致會令錯誤原因難以分辨。
先分清：隔離 staging 全測，還是正式站受限煙霧測試
環境邊界
完整測試在 staging，正式站只做受限煙霧測試
編輯建議：完整回歸測試應在與正式站隔離的 staging 進行：付款用 sandbox／測試模式、測試卡與受控信箱，Webhook 與高風險排程指向測試環境。不要在仍然收單的正式站把 sandbox 全站開啟，也不要讓測試訂單觸發真付款、真退款或真顧客通知。
正式站只做受限煙霧測試。若有需要，先封鎖新結帳（Coming soon／維護模式），核對並處理在途付款與必要寫入，再用低風險方式確認關鍵路徑 [1]。不要在交易中的正式站切換全站 sandbox，也不要把「正式站測試」當成完整回歸。
清理測試訂單前，先確認它是可辨識的 synthetic／測試訂單。若已產生真實付款、退款、發票或履行紀錄，先對賬並保留紀錄，不要直接刪除；刪除測試資料不應抹掉真實交易 [2]。
用一張受控測試訂單走完六段
測試訂單不是正式訂單的替代品。WooCommerce 文件提醒，測試訂單可以像正式訂單一樣觸發訂單電郵、出現在分析數據，而且預設沒有視覺差異或特殊狀態 [2]。所以測試前要先安排測試信箱、分析排除與清理，而不是事後補救。
測試資料
先安排清理，再落測試單
編輯建議：選一個低風險、可重複的簡單商品；若網店有可變商品、優惠券、運費級距或稅務規則，另加一個代表案例。完整付款測試放在隔離 staging 的 sandbox／測試模式；不要用顧客真卡或真地址。若只能在正式站做受限煙霧驗證，先封鎖新結帳，處理在途付款，記錄測試訂單編號，並在清理前確認沒有真實付款或退款紀錄 [2]。停用電郵外掛亦未必攔截經 SMTP 或其他外掛 API 發出的郵件，仍要核對郵件服務記錄 [2]。
六段回歸路徑：由產品頁到背景工作
以下次序是編輯建議，目的是讓失敗點容易被定位；官方文件只直接支持各段的個別行為，沒有規定這個測試順序。
手機版：六段回歸路徑
- 1. 產品頁與價格
簡單／可變商品、售價、庫存、圖片；加入購物車後，項目、數量與價格要正確。
- 2. 購物車
數量、優惠券、移除商品；核對運費估算、稅額、小計與總額。
- 3. 結帳
訪客與會員、必填欄位、運送方式、稅項、付款方式、訂單摘要與錯誤提示；可提交訂單，沒有重複訂單。
- 4. 付款與 Webhook
Gateway 交易編號、金額與狀態；訂單備註與 Webhook 送達；付款、訂單狀態與 gateway 紀錄要符合該付款方式的預期。
- 5. 訂單狀態與庫存
實體商品常見是 Processing → 手動 Completed；全虛擬＋可下載、離線付款、延遲通知或 authorize-only 可能有不同狀態。庫存變化視追蹤與狀態設定，逐項核對。
- 6. 電郵、日誌與排程
訂單與管理員電郵、SMTP 記錄、WooCommerce logs；部分背景工作經 Action Scheduler。未到時間的 pending 正常，查逾期、卡住或新增 failed。
全部通過：才可視為更新後回歸完成。
任何一段失敗：保持結帳封鎖或限制，記錄訂單／交易編號與錯誤，再回 staging 重現；收入路徑未修好前不要解除限制。
購物車
- 改數量、套優惠券、移除商品，重新計算。
- 核對運費估算、稅額、小計與總額。
通過：數字合理，沒有重複項目。
結帳
- 訪客與會員各走一次（若兩者都開放）。
- 檢查必填欄位、運送方式、稅項、付款方式、訂單摘要與錯誤提示。
通過：可提交訂單，沒有新的 JavaScript 錯誤或重複訂單。
付款與 Webhook
- 在 gateway 儀表板核對交易編號、金額與狀態。
- 看訂單備註是否收到授權、捕獲或失敗訊息；確認 Webhook 有送達。
通過：付款、訂單狀態與 gateway 紀錄符合該付款方式的預期。若狀態未更新，先查 Webhook [4]。
訂單狀態與庫存
- 實體商品常見是 Pending payment → Processing → Completed；Processing 代表已付款、等待履行，通常由店員出貨後手動 Completed [4]。
- 全虛擬＋可下載、離線付款、延遲通知或 authorize-only 可能有不同狀態；庫存變化亦取決於追蹤與狀態設定。
通過：狀態與庫存變化符合你的商店設定，而不是套用單一固定路徑。
電郵、日誌與排程
- 訂單電郵與管理員通知送到公司控制信箱；核對 SMTP／郵件服務日誌。
- 到 WooCommerce > Status > Logs 與 Scheduled Actions，查看背景工作；未到時間的 pending 正常，重點查逾期、卡住或新增 failed。
通過：通知與背景工作符合預期。Action Scheduler 是 WooCommerce 的背景工作佇列 [5]；部分訂單通知或付款相關工作會經它執行，實際取決於外掛與設定，不是所有通知或付款都經它執行。
五個最常見的「假正常」
編輯建議：以下不是 WooCommerce 的官方診斷清單，而是把常見假象整理成快速停損點。遇到任何一項，都不要用「再落一張單試試」當成調查。
失敗時，先留住證據再決定回滾
編輯建議：回歸測試失敗時，第一個動作不是按「更新」或「還原」，而是停止製造更多測試訂單，並把現場記錄下來。
- 若結帳、付款或訂單建立等收入路徑壞掉，保持結帳封鎖或限制，不要只停止測試；必要時維持 Coming soon，直到修正與重測完成。
- 記錄訂單編號、測試時間、gateway transaction ID、錯誤原文、瀏覽器與裝置、相關外掛版本及截圖。
- 在 staging 重現同一段路徑；不要在正式站用顧客資料重試。
- 若付款已捕獲但訂單缺失，先查 gateway Webhook、訂單備註與交易紀錄，再決定補單或退款；不要重複收款。
- 還原前先保留／匯出新產生的真實訂單、付款、退款與會員資料；不要把備份之後的新交易覆蓋掉。
- 不要把 staging 資料庫直接倒回正式站。由建立副本到測試期間，正式站可能已有新訂單、會員、評論、庫存與優惠券變動；覆蓋會令新資料消失。回滾需要最新一致備份、授權與明確步驟。
更新後第一個營業日看甚麼
編輯建議：以下是營運觀察重點，不是服務保證或事故處理承諾。
- 第一筆真實低風險訂單的付款狀態、訂單備註、庫存變化與顧客收到的通知。
- 付款 gateway 儀表板有沒有重複交易、未預期退款或長時間 pending。
- WooCommerce logs、PHP 錯誤、Action Scheduler 的逾期、卡住或新增 failed；未到時間的 pending 不是異常。
- CRM、物流、會計與客服整合有沒有收到重複或錯誤事件。
- 前台是否仍見舊價、舊版面或舊庫存；若用頁面快取或 CDN，應核對實際內容版本，不要只看一次 HTTP 200。
- 不要在正式站把 sandbox 全站開啟；正式站只做受限煙霧測試，完整付款測試留在隔離 staging。
把觀察結果寫回同一張回歸表，而不是靠記憶或聊天紀錄。下一次更新時，這張表就是你的起點。
常見問題
更新後只看首頁有沒有載入，夠嗎？
不夠。首頁載入只證明某一個頁面能回應；結帳、付款、訂單狀態、電郵與背景工作可以各自失效。至少要走完一次受控測試訂單，並核對 gateway 與日誌。
測試訂單一定要用真卡嗎？
不建議。完整測試應在隔離 staging 用 sandbox／測試模式；正式站只做受限煙霧測試，先封鎖新結帳，不要在全站交易中開啟 sandbox。若必須在正式站驗證，記錄測試訂單，清理前確認不是真實付款／退款紀錄，並把測試數據與正式營業數據分開 [2]。
訂單停在 Processing，是否代表更新壞了？
不一定。Processing 通常代表已付款、等待履行；實體商品由店員出貨後手動 Completed [4]。全虛擬＋可下載、離線付款、延遲通知或 authorize-only 可能有不同狀態，應按商店設定與 gateway 文件核對，不要套用單一路徑。
資料庫更新提示可以跳過嗎？
不應跳過。WooCommerce 要求先完成資料庫更新，才繼續測試商店 [1]；執行前要先備份資料庫 [3]。若更新未完成，前台測試結果不能代表更新後的實際狀態。
測試訂單會寄真電郵或計入分析嗎？
可以。WooCommerce 文件明確提醒測試訂單可能觸發訂單電郵並出現在分析數據，而且沒有預設視覺標記 [2]。測試前要先安排受控信箱、分析排除與清理。
更新失敗時可以馬上還原備份嗎？
不要未經核對就直接還原。先保持結帳封鎖或限制，保留新訂單、付款、退款與會員紀錄，確認備份時間點與還原步驟；備份之後的新交易可能不在備份內。
來源
更新後，先把收單路徑走完一次
Managed-WP.™ PRO 提供 WordPress 專業代管服務。若你正處理 WooCommerce 更新後的回歸測試，先把測試訂單、付款狀態、訂單電郵與背景工作記錄下來，再按實際環境與團隊確認支援範圍。
前往客戶入口編輯說明：本文由 Managed-WP.™ PRO 編輯團隊根據上述官方文件整理；標示「編輯建議」的內容是實務建議，不是 WooCommerce、付款服務商或主機商的保證。版本、介面與外掛行為可能變更，請以你的實際環境及供應商文件為準。