自動化測試是什麼：測試種類白話解釋與驗收怎麼看
報價單上出現「測試」這一項，很多業主的第一個念頭是：這個能不能省？畢竟功能做完了、點起來也正常，為什麼還要另外花時間？
問題在於，「現在點起來正常」和「三個月後加了新功能還正常」是兩件完全不同的事。測試買的不是今天的正確，而是未來每一次改動的安全感。
這篇用非工程師聽得懂的方式，解釋測試到底在做什麼、哪些值得自動化、以及驗收時該怎麼確認。
先建立一個比喻
把軟體想成一棟房子的水電。
單元測試像是逐一檢查每個開關、每個插座本身能不能通電。範圍最小、跑起來最快，出問題時你馬上知道是哪一個元件壞了。
整合測試是檢查幾個部分接在一起會不會出事：開關接上電燈、電表接上迴路。很多問題不是單一元件壞掉，而是接起來之後行為不如預期。
端對端測試（End-to-End，簡稱 E2E）是模擬一個真人從頭走一遍：進門、開燈、洗澡、確認有熱水。它檢查的是完整流程，最貼近真實使用，但也跑得最慢、最容易因為無關的小改動而誤報。
| 類型 | 檢查什麼 | 速度 | 抓到問題時的定位難度 |
|---|---|---|---|
| 單元測試 | 單一功能邏輯本身 | 最快 | 最容易，直指某段邏輯 |
| 整合測試 | 多個部分串起來的行為 | 中等 | 中等 |
| 端對端測試 | 使用者完整流程 | 最慢 | 較難，要往下追 |
三種不是互相取代，而是各自負責不同層次。健康的專案通常是單元測試數量最多、端對端測試只覆蓋最關鍵的幾條流程——因為 E2E 維護成本高，全部都用 E2E 寫，跑一次要很久，久到最後沒人願意跑。
自動化真正省下的是什麼
手動測試並不是錯的做法，新功能第一次做出來，本來就該有人實際點過。自動化要解決的是另一個問題：重複。
系統上線之後，每一次改動都可能影響到看似無關的地方。改了會員等級的計算，結果折扣算錯；調整了訂單狀態，結果報表數字對不起來。這類「新東西弄壞舊東西」的狀況叫做回歸，是維護期最常見、也最傷信任的問題。
沒有自動化測試時，要防回歸只有兩條路：每次改版都請人把所有舊功能重測一遍，或是乾脆不測、等客戶回報。前者是反覆付出的人力，而且人會累、會漏；後者則把成本轉嫁到線上事故與客訴。
自動化測試的意義，是讓這份重複檢查變成可以隨時、大量、低成本執行的東西。它同時還有一個常被忽略的副作用：測試會逼開發者把邏輯寫得可被驗證，而這通常也意味著結構更清楚、更好維護，和技術債的累積速度直接相關。
什麼該自動化，什麼不必
不是所有東西都值得寫測試。判斷標準可以用兩個問題：出錯的代價高不高？會不會重複發生？
優先自動化：
- 牽涉金錢的邏輯：計價、折扣、分潤、退款、餘額異動。這類錯誤會直接變成財務損失或信任危機。
- 權限判斷：誰能看到什麼、誰能改什麼。權限出錯屬於資安事件，不是小瑕疵。
- 核心交易流程：下單、付款、預約、送審這類主要路徑，用少量端對端測試守住。
- 複雜且規則多的計算：運費級距、稅務處理、狀態轉換規則，這些人工測很容易漏掉邊界情況。
- 修過的 Bug：每修一個問題就補一個測試，確保它不會再回來。這是成本效益最高的一種。
不必或不急：
- 純視覺呈現：顏色、間距、字級這類靠眼睛判斷的東西，自動化的投報率低。
- 一次性或即將淘汰的功能：活動頁、短期專案，寫測試的效益追不上壽命。
- 外部服務本身的行為：你要測的是自己接得對不對，不是替對方測他們的系統。
- 還在頻繁變動的早期功能：需求每週都在改的階段，測試會跟著一直重寫，可以等穩定下來再補。
開發端測試與業主端驗收的分工
這兩件事經常被混為一談，導致驗收時雙方期待落差。
開發端的測試回答的是：程式的行為符不符合當初寫下來的規則。它由開發團隊執行，多半是自動化的，跑在每一次改動之後。
業主端的驗收回答的是：這套系統符不符合我的業務需要。它必須由真正懂業務的人來做，因為只有你知道「這個折扣情境在我們公司其實不存在」或「這個欄位業務不會填」。
換句話說，自動化測試全綠不等於可以驗收通過，兩者驗的是不同的東西。驗收該怎麼設計標準、缺陷怎麼分級、怎麼跟付款節點綁在一起，在軟體驗收怎麼做裡有完整流程；而驗收標準的源頭，其實是當初的需求文件寫得夠不夠具體。
驗收時怎麼確認廠商真的有做
不懂程式也能問出真相，重點在問法。
請對方實際跑一次給你看。正常情況下，測試是一道可以重複執行的程序，結束後會列出通過與失敗的項目。看不到這個東西，就要追問原因。
問關鍵流程有沒有被涵蓋。不要問「測試覆蓋率多少」這種容易被一個數字搪塞的問題，改問「下單到付款這條路有沒有自動化測試」「權限判斷有沒有測」，答案具體很多。
要求示範一次失敗。請對方刻意把某段邏輯改壞，看測試會不會變紅。這是最誠實的檢查——永遠不會失敗的測試，跟沒有測試是一樣的。
把測試寫進交付物。測試程式碼應該和原始碼一起交付，並且能在你這邊或後續廠商手上跑得起來。NETVANA 在專案費用結清後會完整移交原始碼、設計檔案與相關文件，測試屬於原始碼的一部分。
確認測試在什麼時機執行。理想狀態是每次改動都自動觸發，而不是靠人記得要跑。這件事屬於交付流程的一環，可以在談軟體開發流程時一併確認——以兩週為一個 Sprint、每期交付可操作 Demo 的節奏，本身就預設了每一期都要確保舊功能沒被弄壞。
既有系統完全沒有測試怎麼辦
這是最常見的真實處境，答案不是停下來把測試補滿。
務實的順序是這樣：先替最近出過事的地方補測試，因為它證明了自己脆弱；再替改動最頻繁的區域補，因為那裡的回歸風險最高；最後是出錯代價最大的部分，通常是金流與權限。其餘的可以在日後每次碰到時順手補上。
這是一種持續償還而不是一次結清的作法，和處理其他技術債的邏輯一致。相對地，也要接受一件事：測試補得不夠的系統，每次改版都需要更長的人工檢查時間，這筆工時會出現在你的維護合約裡，只是換了一個名目。
另外提醒一個談判時的實用角度：如果你打算在未來更換維護廠商，有沒有測試會直接影響接手的難度。新團隊面對一套沒有測試的系統，只能靠閱讀程式碼與猜測來判斷改動會不會出事，接手期會拉長，初期的報價也會反映這份不確定性。反過來說，一套帶著測試交付的系統，等於附上了一份可執行的行為說明書——它描述的不是「當初想做什麼」，而是「現在實際會怎麼運作」，這件事在人員異動或廠商更替時特別值錢。
測試不是為了證明系統今天是對的，而是為了讓它在明天、下個月、換了維護廠商之後，還能被安全地改動。當你評估一份報價時，把測試當成降低未來改版風險的支出，而不是可以先砍掉的選配，判斷會比較接近真相。
如果你正在規劃新專案，或手上的系統改一次就怕壞一次，和 NETVANA 談談你的狀況。軟體服務採詢問報價制，沒有固定套餐，我們會先釐清現況與風險再給建議；顧問服務也包含架構審查與技術盡職調查，各項服務內容可以看軟體服務介紹。
延伸閱讀：驗收該怎麼設計標準與付款節點，看軟體驗收怎麼做；想理解改一個地方為何要花很久，看技術債是什麼；上線後的檢查與支援算在誰身上，看網站維護費用包含什麼；時程一直往後延的根因，看軟體專案為什麼總是延誤；合約模式會影響測試怎麼排，看固定報價還是敏捷開發；懂了測試種類，就更容易寫出有效的回報，可以看怎麼跟開發廠商回報問題；想知道測試環境裡跑的是什麼測試可以接著看，可以看測試環境、正式環境與部署白話指南；壓力測試也是這篇提到的測試種類之一，可以看活動檔期流量高峰怎麼準備。
