數位與系統・Knowledge
使用者驗收測試（UAT）
客製系統上線前由實際使用者依規格書逐項操作、決定能不能收貨的最後一關；通過的依據是測試案例與驗收紀錄，不是開發端的示範。
關鍵事實
- 誰來測：實際使用系統的承辦人、倉管或會計，而不是開發端或資訊人員代測
- 測什麼：規格書列出的每個功能、各角色核心流程、例外處理、權限、報表與資料移轉筆數
- 依據文件：需求規格書、測試案例清單、驗收紀錄表三份文件對照
- 通過條件：每個測試案例都有結果紀錄，未過項目列出來源、負責方與重測日
- 跟誰搞混：常與開發端的功能測試或系統測試混用，三者測的人與目的都不同
- 法規連動：《著作權法》原始碼歸屬與《個人資料保護法》權限分層都在驗收項目內確認
白話解釋
使用者驗收測試是客製系統交付前，由業主端實際使用的人照著規格書一條一條操作，確認系統做到契約約定內容的程序，簡稱 UAT。最容易搞混的是它與開發端自己做的功能測試：功能測試由工程師驗證程式有沒有錯，使用者驗收測試則由承辦人驗證流程能不能在真實工作裡跑完，兩者不能互相取代。
另一個混淆是把開發端的操作示範當成驗收，示範只證明開發端會用，不證明承辦人會用。驗收的產出是一份驗收紀錄表，列出每個測試案例的結果、未過項目的來源與重測日期，簽認之後才進入切換上線與付款節點，也才啟動保固與維運計畫。
你什麼時候會遇到它
簽客製系統開發契約時看到付款條件綁驗收；開發完成後收到測試案例清單要排人操作；上線後同仁反映系統與當初講的不同，回頭查驗收紀錄時。
常見情境與對策
- 進銷存系統開發完成，開發端用自己的資料示範一輪後要求簽驗收。——不以示範代替驗收，要求提供測試案例清單，由倉管與會計用公司的真實商品清單與單據各跑一遍，結果填進驗收紀錄表再決定簽不簽。
- 案件資料庫試匯舊資料後，驗收時發現部分當事人被合併成同一人。——把這一項列為資料問題而非程式錯誤，回到核對報告補確認差異，重新試匯後再測該項，其他已通過項目不必重測。
- 驗收時承辦人覺得提醒通知的節奏與想像不同，要求改。——先回規格書看簽認的提醒規則表，屬規格內的由開發端調整，屬規格外的走變更單並評估時程，避免驗收變成無限追加。
LINE 諮詢
把系統開發的現況與需求傳過來，先免費書面初判。
- 傳什麼
- 現有網站網址與後台權限還沒有網站也能先談
- 商品或服務清單、作業流程說明表單樣張或試算表皆可
- 需求清單一句話也行
- 多久回
- 週一至週五 09:00–18:00 依序回覆；LINE 全天可傳資料
- 下一步
- 免費書面初判
- 約時間細談
- 委任開發
先傳資料做初判，需要時再約時間細談
程序怎麼走
- 規格階段就定驗收標準：業主專案窗口與開發端在需求規格書簽認時，一併寫下每個功能的驗收條件與誰來測，之後測試案例直接從規格書展開。
- 開發端交付測試案例清單：開發完成後由開發端提供測試案例清單，每案寫操作步驤、輸入資料與預期結果，業主確認清單有涵蓋各角色核心流程、例外處理、權限與報表。
- 實際使用者排程操作：業主指定承辦人、倉管、會計等實際使用者，在測試環境用公司真實資料逐案操作，開發端在旁記錄而不代操作。
- 填寫驗收紀錄表：每個測試案例填通過或未通過，未通過的註明是程式錯誤、資料問題還是規格理解落差，並列負責方與預計重測日。
- 補正與重測：開發端修正程式錯誤後重測該項；資料問題由業主補確認後重新匯入；規格外需求走變更單，不在本次驗收範圍。
- 簽認與銜接上線：全部案例通過後由專案窗口簽認驗收紀錄，接著排切換上線日、教育訓練與原始碼、部署文件、操作手冊的交付。
先看清楚
驗收紀錄沒有留下每個案例的結果，上線後出問題時雙方各說各話；資料移轉的驗收只看筆數對不對，沒有逐筆抽核欄位內容；權限驗收漏掉外部協力與離職帳號停用的情境。
常見錯誤
- 把開發端的操作示範當成驗收，簽了字才發現承辦人根本跑不完流程
- 驗收時提出規格書沒寫的新需求，全案拖在驗收階段無法上線也無法付款
- 由資訊人員一個人代替所有角色測試，上線後倉管與會計的實際卡點全部沒測到
- 原始碼與部署文件沒列進驗收項目，日後要換團隊維護才發現拿不到完整程式
行動前自查清單
- 需求規格書簽認時已附每個功能的驗收條件與測試負責人
- 測試案例清單涵蓋各角色核心流程、例外處理、權限、報表與資料移轉
- 由實際使用者用公司真實資料操作，開發端只記錄不代操作
- 驗收紀錄表逐案填結果，未過項目標示來源、負責方與重測日
- 原始碼、資料庫、部署文件與操作手冊列入驗收交付項目
- 備份已實際還原一次，離職帳號停用與外部協力權限情境已測
常見問題
使用者驗收測試（UAT）是什麼？
客製系統上線前由實際使用者依規格書逐項操作、決定能不能收貨的最後一關；通過的依據是測試案例與驗收紀錄，不是開發端的示範。使用者驗收測試是客製系統交付前，由業主端實際使用的人照著規格書一條一條操作，確認系統做到契約約定內容的程序，簡稱 UAT。
最容易搞混的是它與開發端自己做的功能測試：功能測試由工程師驗證程式有沒有錯，使用者驗收測試則由承辦人驗證流程能不能在真實工作裡跑完，兩者不能互相取代。另一個混淆是把開發端的操作示範當成驗收，示範只證明開發端會用，不證明承辦人會用。驗收的產出是一份驗收紀錄表，列出每個測試案例的結果、未過項目的來源與重測日期，簽認之後才進入切換上線與付款節點，也才啟動保固與維運計畫。
什麼時候會遇到使用者驗收測試（UAT）？遇到了該怎麼辦？
簽客製系統開發契約時看到付款條件綁驗收；開發完成後收到測試案例清單要排人操作；上線後同仁反映系統與當初講的不同，回頭查驗收紀錄時。提醒：驗收紀錄沒有留下每個案例的結果，上線後出問題時雙方各說各話；資料移轉的驗收只看筆數對不對，沒有逐筆抽核欄位內容；權限驗收漏掉外部協力與離職帳號停用的情境。如需協助，可將文件交由偉騰開發興業免費書面初判（加 LINE「偉騰開發」傳文件即可）。
法源出處
對應的偉騰服務
相關名詞
- 需求規格書與規格凍結:需求規格書是把「系統要做什麼」寫成可驗收條文的文件；規格凍結是雙方簽認後，變更一律走變更單與報價的時點。客製系統開發的報價、時程與驗收，都以這份文件為準。
- 應用程式介面（API）:系統之間講好的溝通規則：你的網站用它跟金流、LINE、發票或別人的系統交換資料。
- 企業資源規劃與進銷存:進銷存管進貨、銷貨、庫存、應收付；ERP 再把會計、生產、人資放進同一套資料。
延伸閱讀:更多「數位與系統」與常查名詞
- 響應式網頁設計（RWD）
- 搜尋引擎優化（SEO）
- 核心網頁指標
- SSL 憑證與 HTTPS
- 內容管理系統（CMS）
- 客戶關係管理系統（CRM）
- 金流串接
- 電子發票串接
- 網站無障礙規範
- 漸進式網頁應用（PWA）
- 隱私權政策與個資告知
- 網域與 DNS
免費工具
別逐字研究了,把文件傳過來。
公文、謄本、稽查紀錄整份交給偉騰,前臺東縣環保局長團隊 24 小時內免費書面初判:狀況多嚴重、期限剩多少、下一步做什麼。LINE 傳文件免費判讀