第一筆訂單不該是除錯現場:上線前的端對端測試

電商上線前一天,測試環境的所有測試都是綠的:假卡號刷得過、假發票開得出、物流單建得起來。然後第一筆真實訂單進來——付款通知晚到、發票欄位被正式環境退件、物流單建立失敗。消費者在 LINE 問「我付款了為什麼沒收到確認」,而你的工程師正在正式機上翻 log。第一筆訂單變成除錯現場,這個場景我們見過太多次,包括在自己身上。

我們的自營電商第一張正式訂單也出過事:兩個 bug 互相掩蓋,單元測試全綠,組合在一起卻讓訂單走進錯誤狀態。那次之後,我們把一條規矩寫進團隊文化:測試環境全綠只是及格線,上線前必須用真實金流、真實發票、真實物流,完整跑一遍端對端。

為什麼測試環境會騙你

不是測試環境不好,是它天生跟正式環境不一樣:

• 金流測試環境永遠成功。假卡號不會被風控擋、超商代碼不用真的去繳、付款通知即時到達。正式環境的延遲、重送、風控拒絕,測試環境全都遇不到——而你的系統處理這些狀況的程式碼,等於從來沒被執行過。
• 發票測試環境不驗真。統編格式、買受人欄位、字軌配號,正式環境的驗證嚴格得多,測試環境過了不代表正式環境會過。
• 物流測試環境沒有實體世界。沒有真的包裹、真的門市、真的取貨期限。門市關轉店、逾期退回這些場景,只存在於正式環境。
• 設定本身就是變數。API 金鑰、端點網址、回調網址、憑證,測試與正式各一套。測試環境測得再熟,也驗不到「正式環境的設定填對了沒」——而上線日出包,一半以上就是設定問題。

我們的上線前 checklist:用真單走完整條鏈路

切到正式環境後、對外開賣前,自己當第一個客人,用真錢下單:

1. 每一種付款方式各刷一筆小額真單:信用卡、超商代碼(真的走到超商繳費)、貨到付款、Apple Pay、分期。確認付款通知進來、訂單狀態正確、確認信與 LINE 通知都有發。
2. 發票開一張真的:確認自動開立觸發、號碼取到、載具與統編場景各測一次,然後測作廢重開(細節見電子發票自動開立那篇)。
3. 物流寄一件真的給自己:建單、印單、寄件、到店通知、取貨,整條走完。順便測一次金額變更的作廢重開。
4. 逆向流程至少走一次:取消訂單、退款、發票作廢或折讓。逆向流程上線後第一週一定會用到,不要賭——而且它出錯時牽涉的是「錢已經收了」的狀態,善後遠比正向流程麻煩。
5. 用手機、用消費者的網路環境再走一次:桌機開發者測過不算數,真實消費者九成在手機上,而且是在社群 App 的內建瀏覽器裡——那個環境的彈窗、跳轉、回傳行為都跟一般瀏覽器不同,不少付款流程就是死在這裡。

這一輪跑完,花費不過幾百元手續費和一天時間,換到的是「每一段鏈路都被真實世界驗證過」。相比第一週在正式環境救火的成本——工程師的緊急工時、消費者的第一印象、客服的信任赤字——這是全世界最便宜的保險。

交付前自己當第一個用戶。你不敢用真錢下的單,憑什麼讓消費者下?

「丟給客戶自己測」在我們看來是工程失格——我們交付的每個電商案,金流、發票、物流的真單驗證都是標準程序,因為我們自己每天在收單,深知第一印象壞掉有多難救。想了解這套交付標準,歡迎看看電商系統建置服務與過往作品,或直接聊聊你的上線計畫。