購物網站運費算錯怎麼驗收：免運折扣測試矩陣

文章目錄

• 1. 先寫清楚商店運費規則
• 規則至少要寫清楚五件事
• 規則文件要能對照系統設定畫面
• 2. 區分折扣前後的計算基礎
• 常見的兩種計算基礎
• 多張折價券疊加時的計算順序
• 3. 建立門檻上下的測試資料
• 單一門檻的測試組合
• 多門檻與多配送方式的交叉測試
• 4. 核對前台訂單與付款金額
• 三方金額比對表
• 手機與桌機結帳流程要分開測
• 5. 處理例外並留下驗收紀錄
• 常見例外狀況清單
• 驗收紀錄該保留哪些內容

購物網站運費算錯怎麼驗收，做法是針對免運門檻、折扣計算基礎與配送方式三個維度，建立邊界測試矩陣，逐一測試門檻金額上下各一元的情境，並核對前台顯示與金流實際請款金額是否一致。這類問題在中小型購物網站上線前最常被忽略，往往等到客訴湧入才發現規則早就寫錯。假設一家台中的生活選物電商，滿 NT$1,000 免運，上線後卻陸續收到「明明滿額卻還是被收運費」的留言，追查下去，問題通常不是程式壞掉，而是當初根本沒有人把運費規則寫清楚、測清楚。

本文重點摘要

• 購物網站運費算錯怎麼驗收的核心做法，是用門檻上下各一元的邊界值做測試，不是只測整數金額
• 免運門檻該用折扣前還是折扣後金額計算，必須在規則文件寫清楚，否則前後台認知會不一致
• 多種配送方式搭配滿額折扣時，至少要有一張測試矩陣表，列出金額、折扣、配送方式三個變數的交叉組合
• 前台顯示金額與金流實際請款金額若不一致，問題通常出在運費計算時機點，不是金流商的錯
• 每一項測試都該留下對照紀錄，上線後若有客訴，才有依據回頭比對是規則錯還是個案例外

先寫清楚商店運費規則

運費驗收的第一步不是測試，是把規則寫成文件。很多購物網站的運費邏輯只存在開發人員的記憶裡，或是散落在某次 LINE 對話紀錄中，等到要驗收時，連負責人自己都講不清楚「滿額免運」算的是商品原價還是折扣後金額。這種模糊地帶，就是日後客訴與退款爭議的根源。

規則至少要寫清楚五件事

一份完整的運費規則文件，至少要寫明：免運門檻金額、門檻計算基礎（原價或折扣後）、各配送方式的基本運費、是否有離島或偏遠地區加價、以及特殊商品（如冷凍、大型家具）是否排除於免運資格之外。假設一家做手工烘焙食品的網家，滿 NT$800 免運，但冷凍蛋糕需要額外加收 NT$150 的保冷運費，若規則沒寫清楚這類例外，前台很容易出現「滿額卻還要付保冷費」的計算錯誤，變成需要客服逐一解釋的負擔。

規則文件要能對照系統設定畫面

規則寫完後，下一步是逐條對照後台系統的實際設定畫面，確認每一條規則都有對應的設定欄位，而不是「寫了但系統做不到」。常見的落差是行銷端想要「滿兩千折兩百、滿三千免運」，但系統的折扣模組與運費模組是兩套獨立邏輯，彼此不互通，導致同一張訂單被重複套用規則或互相覆蓋。建議規則文件定稿後，由開發人員或資訊人員實際操作一次設定畫面，逐條打勾確認可行，再進入下一階段的測試。

運費規則沒有白紙黑字寫清楚，驗收就無從測起。先把規則變成文件，再談測試。

區分折扣前後的計算基礎

折扣後金額該不該算進免運門檻，是這類驗收中最容易吵起來的問題，怎麼選對購物網站運費算錯怎麼驗收的結果影響最大。假設免運門檻是 NT$1,000，商品原價 NT$1,200，會員使用了 NT$300 折價券，折扣後實付金額是 NT$900。

這時候門檻是用原價的 NT$1,200 判斷（符合免運），還是用折扣後的 NT$900 判斷（不符合免運）？兩種邏輯都有店家在用，重點是系統設定要跟行銷規則一致，不能前台顯示一套、結帳邏輯又是另一套。

常見的兩種計算基礎

第一種是「折扣前判斷」，也就是用商品原始小計金額去比對免運門檻，折價券只影響最終付款金額，不影響運費資格。第二種是「折扣後判斷」，用實際應付金額（扣除折價券後）去比對門檻，這種做法對店家成本控管較有利，但容易讓使用者覺得「怎麼湊到門檻了還要付運費」而產生不滿。兩種做法沒有絕對對錯，但一旦選定，就要在網站的運費說明頁面明確寫出來，避免使用者誤解。

多張折價券疊加時的計算順序

如果網站同時支援會員折扣、滿額折扣、單品優惠券疊加使用，計算順序會直接影響最終金額是否正確。常見的做法是先套用單品優惠，再套用滿額折扣，最後才判斷運費門檻，但也有系統反過來處理。順序不同，同一張訂單可能算出不同結果。驗收時務必針對「多重折扣疊加」的情境單獨測試，不能只測單一折扣的狀況。

免運門檻用原價還是折扣後金額判斷，沒有標準答案，但規則一旦模糊，客訴一定找上門。

建立門檻上下的測試資料

驗收運費邏輯最有效的方法，是針對免運門檻金額，建立「門檻上下各一元」的邊界測試資料，而不是只測試整數金額。假設門檻是 NT$1,000，測試資料就該包含 NT$999（應收運費）、NT$1,000（剛好免運）、NT$1,001（應免運）這三個關鍵點，而不是只測 NT$1,500 這種明顯高於門檻的金額。多數運費算錯的問題，都發生在邊界值附近，而不是中間值。

單一門檻的測試組合

以下是單一免運門檻（假設門檻為 NT$1,000，基本運費 NT$80）的測試矩陣範例，店家可依自家實際門檻金額套用相同邏輯：

多門檻與多配送方式的交叉測試

如果網站設計了多段式運費（例如滿 NT$500 折運費 NT$30、滿 NT$1,000 全免運），且同時提供宅配與超商取貨兩種配送方式，測試資料就必須做交叉組合，而不是分開測試。假設一家台中的生活雜貨網店同時設定這兩種規則，測試矩陣至少要涵蓋「宅配＋各門檻區間」與「超商取貨＋各門檻區間」兩組，因為超商取貨的基本運費通常較低，門檻判斷邏輯若共用同一套程式碼，很容易在其中一種配送方式上出現遺漏。

只測整數金額測不出問題，門檻上下各一元的邊界值才是運費邏輯最容易出錯的地方。

核對前台訂單與付款金額

測試資料跑完，下一步是核對前台顯示金額、訂單紀錄金額與金流實際請款金額這三者是否完全一致。這一步最常被跳過，因為多數團隊測完前台顯示沒問題就結案，卻沒有回頭檢查金流商實際收到的請款金額，是不是跟畫面上顯示的一樣。

三方金額比對表

建議每一筆測試訂單都填寫對照表，逐欄比對三個金額來源：

若發現後台訂單金額跟前台顯示不同，問題通常出在運費是「下單當下即時計算」還是「送出訂單後才重新計算」的時機差異，中間若商品庫存或優惠券狀態發生變化，兩次計算結果就可能不同。

手機與桌機結帳流程要分開測

不少購物網站的手機版結帳頁與桌機版使用不同的前端套件，運費計算邏輯雖然共用同一套後端 API，但顯示層的呼叫時機可能不同，導致手機版畫面顯示的運費跟實際送出的訂單金額有落差。建議每一組邊界測試資料，都在手機瀏覽器與桌機瀏覽器各跑一次，不能只測單一裝置就視為驗收完成。

處理例外並留下驗收紀錄

運費規則測完主要情境之後，一定還會遇到規則沒寫到的例外狀況，例如：訂單中有商品本身設定「不適用免運」、使用者在結帳最後一刻取消優惠券、或是配送地址在送出訂單後才切換成離島地區。這些例外狀況如果沒有在驗收階段列出來逐一確認，上線後就會變成客服每天手動處理的灰色地帶。

常見例外狀況清單

以下是購物網站運費驗收時常見需要額外測試的例外情境，店家可依自身商品與金流組合增減項目：

• 單張訂單同時包含免運商品與不適用免運商品
• 使用者在結帳頁切換配送地址，是否重新計算運費與免運資格
• 優惠券在結帳最後一步被取消，運費是否正確回復
• 訂單因超商取貨地點調整，運費是否跟著變動
• 客服後台手動修改訂單金額，是否會影響已請款的金流紀錄
• 促銷活動結束當下，進行中的訂單是否仍套用舊運費規則

驗收紀錄該保留哪些內容

每一項測試完成後，建議保留測試情境、預期結果、實際結果、測試人員與測試時間這五項紀錄，並集中存放在同一份文件或試算表中。假設上線後有使用者反映運費金額不對，客服可以立刻回頭查這份紀錄，確認當初是否測過這個情境，而不是每次都要重新從頭排查。這份紀錄同時也是日後規則調整時的參考依據，避免同樣的錯誤在下次改版時重複發生。

沒有驗收紀錄的運費測試，等於沒測過，問題永遠要等客訴才會浮現。

例外情境占了運費客訴的大宗，驗收時花時間列清單，上線後能省下大量客服工時。

運費規則複雜又怕上線後出包？

欣創數位科技提供購物網站建置與系統驗收顧問服務，協助釐清運費、折扣與配送邏輯的規則設計與測試流程。歡迎洽詢專業諮詢與報價，一起把上線前的風險降到最低。