文章目錄
「首頁看起來沒問題，手機版也有做，那就上線吧。」
如果驗收停在這裡，第一個發現問題的人，可能會是準備詢價的客戶。他按了送出，畫面說成功，你的後台卻沒收到資料。也可能網站本身沒壞，只是通知寄到已離職同事的信箱。
網站驗收不是逐頁看完，而是確認約定的工作真的能完成。 畫面、流程、資料與交接，都要有能重現的檢查方式。
如果目前還在詢價，先用網站報價比較的七個項目對齊交付範圍。等到要上線才討論「原來這也要做」，往往已經太晚。
驗收前，先把測試條件準備好
請廠商提供本次驗收的網址、版本、測試帳號、已完成項目與已知限制。你則找一位未參與製作、但熟悉業務的同事，照平常工作方式操作。
準備一組沒有真實個資的測試資料，並約定測試記錄如何清理。需要串接付款或寄信時，先確認測試環境及收件對象，不要直接拿正式客戶練習。
每一項至少寫出三件事：
- 從哪裡開始，例如從手機的服務頁進入諮詢。
- 要做什麼，例如填完必填欄位後送出。
- 如何確認完成，例如後台只出現一筆內容正確的詢問。
下面八種情境適合一般服務型官網。會員、電商、預約與多語網站，還要加入各自的核心流程；沒有購物車的網站，不必硬驗購物車。
情境一：用自己的手機找一項服務
不要只看電腦上縮小的視窗。請用實際手機，從首頁找出服務、進入內頁，再找到聯絡方式。
觀察選單能否開關、按鈕是否被固定區塊擋住、文字是否需要左右滑動。打開表單後，也要看螢幕鍵盤會不會遮住正在輸入的欄位。
通過標準不是每台手機一模一樣，而是約定支援的裝置都能完成主要任務。 測試紀錄要留下裝置、瀏覽器、出問題的頁面，不要只寫「手機版怪怪的」。
情境二：不靠首頁，也能找到下一步
客戶可能從搜尋結果直接進入案例或文章。請從一個內頁開始，確認他能看懂自己在哪裡，接著找到相關服務或回到列表。
再試一次不使用滑鼠，只靠鍵盤切換連結、開啟選單與操作表單。焦點要看得見，順序也要合理。
W3C 的無障礙初步檢查包含鍵盤焦點與表單等基本檢視，也提醒這類快速檢查不能替代完整無障礙評估。驗收時可把它當起點，不要當成通過認證。
情境三：送出表單後，資料確實到達目的地
填一筆有明確測試標記的詢問，確認三個畫面：送出前、送出後、管理端收到的內容。
檢查姓名、聯絡方式、服務選項與備註是否一致。若網站會顯示案件編號，管理端也應能找到對應記錄；若系統不提供編號，就用測試標記與時間核對。
再測試連按送出或重新整理。驗收重點是會不會形成非預期的重複案件，而不是按鈕有沒有變成載入動畫。
同時分清楚：資料儲存成功、通知送出成功、客戶收到回覆，是三個不同結果。 不能用一個「成功」提示包辦。
情境四：通知送到對的人，而且有人接手
請實際確認約定的收件管道。可能是 Email、後台待辦或團隊通知，不一定每種都要有。
以下問題要在交付前有答案：
- 誰是主要窗口，休假時誰接手？
- 通知裡的連結是否指向正式後台？
- 收件人需要登入後，能否看到對應案件？
- 通知延遲或失敗時，資料是否仍保留，誰能查詢？
如果網站採「送出表單後引導加 LINE」，也要確認加好友連結、官方帳號與引導文字正確。點擊 LINE 按鈕，不等於已經完成加好友，更不等於對方已傳訊息。
情境五：故意做錯時，不會把資料弄丟
測試漏填必填欄位、輸入錯誤格式，以及使用不存在的網址。請廠商在受控環境示範服務暫時失敗或連線中斷時的處理方式。
好的錯誤提示會告訴使用者哪裡要改、可以怎麼繼續，並盡量保留已輸入的內容。它不應只顯示一串技術訊息，也不能在失敗時仍宣稱成功。
不要自行對正式站大量連續送出資料來測試防護。流量限制、權限繞過與安全測試，應先約定範圍，由開發者在合適環境驗證並提供結果。相關風險可延伸閱讀網站上線後容易出事的地方。
情境六：未來負責更新的人，自己改一次內容
讓實際維護同事登入後台，修改一段文字、換一張圖片，再預覽與發布。
如果有草稿、排程或多語功能，也要按約定各走一次。沒有規劃後台的網站，則改驗收內容更新的交付流程、處理窗口與費用邊界，不必要求原本沒有的功能。
請同事回答：「下次換人來做，照這份說明能不能完成？」如果只能等開發者分享螢幕才能修改，就還沒有真正完成交接。
另外使用低權限帳號，請開發者示範它不能修改哪些資料。能登入，不代表所有內容都應該能改。
情境七：正式頁面的標題、連結與搜尋設定正確
抽查首頁、服務頁、案例與文章，確認分頁標題、主要標題、圖片及連結沒有留著樣板文字。複製一個正式網址，檢查分享預覽是否符合預期。
請廠商列出正式站與測試站的搜尋設定差異。該公開的頁面不能忘記移除測試用的禁止索引設定；不該公開的資料，則要靠真正的存取權限保護。
Google 說明，noindex 是控制搜尋索引的指示，而且搜尋引擎必須能抓取頁面才能讀到它。因此，驗收時不能把「搜尋不到」當成「外人無法開啟」。
若是改版，也要從幾個舊網址進入，確認仍能找到相對應內容。這裡驗收的是技術設定與使用路徑，不是承諾上線當天就有搜尋排名。
情境八：知道帳號在哪裡，也知道出事找誰
交接不是把密碼貼在一封信裡。至少列出網域、主機、後台、程式庫與第三方服務的管理者、續費窗口，以及各自需要的存取權限。
帳號交接應透過邀請或合適的密碼管理方式完成，不要把正式密碼、API 金鑰寫進公開文件。
請廠商說明備份包含哪些資料，並提供可還原的測試證據。能下載壓縮檔，不代表真的能把網站恢復；由誰協助還原、預計多久回應，也要說清楚。
至於後續維護內容，可以對照網站維護合約到底買什麼，把本次交付與長期支援分開。
問題怎麼記錄，才不會修來修去？
用一張所有人都看得到的表，取代散落在聊天紀錄裡的截圖。
| 欄位 | 示意填法 |
|---|---|
| 情境與版本 | 手機送出諮詢，本次驗收版本 |
| 重現步驟 | 進入服務頁、填表、連按兩次送出 |
| 預期與實際 | 預期一筆，後台出現兩筆 |
| 證據 | 測試時間、頁面網址、去識別化截圖 |
| 影響與負責人 | 造成重複派單，交由開發窗口處理 |
| 複驗結果 | 修正版本、複驗日期、是否通過 |
以上是示意，不是本網站實際發生的事件。
先處理會造成資料外洩、資料遺失或主要流程中斷的問題。其餘依影響安排，不要讓一個字距問題和無法送單排在同一順位。新增功能則另外列需求，避免混進原規格的缺陷修正。
常見問題
不懂程式，也能自己驗收網站嗎？
可以先驗收實際使用情境，例如用手機查服務、送出表單、確認後台收到資料、自己修改內容。程式安全、負載與備份還原則應由開發者提供測試證據。業務驗收與技術測試是互補關係，不是把測試責任全部交給客戶。
網站驗收是不是所有小問題都修完才能上線？
要按影響分級。資料遺失、權限錯誤、主要流程無法完成等問題應先修好；不影響任務完成的視覺細節，可在雙方確認影響、負責人與修正期限後安排處理。這是專案協作方式，實際驗收與付款仍以雙方約定為準。
網站的 Lighthouse 分數很高，就代表驗收通過嗎？
不代表。工具分數可以協助找出部分問題，但不能證明表單資料有正確儲存、通知送到指定窗口、後台權限符合需求，或同事真的會更新內容。驗收需要工具檢查、技術測試與真實情境操作一起做。
結論
驗收的價值，是讓雙方對「完成」有共同證據。
請用手機走流程、確認資料與通知、刻意測試例外、讓維護者自己更新內容，最後交接帳號與責任。這些操作不需要你會寫程式，但能補上只看畫面看不到的缺口。
如果你正在準備網站上線或改版，可以把現有規格與驗收疑問帶來討論，先釐清哪些情境一定要通過，再安排交付。
