封測、公測與試營運怎麼做：招募測試者、問題分級到正式上線判斷

開發團隊說「功能都做完了」，業主心裡想的是「那明天可以上線嗎？」這兩句話之間其實還差一段：系統在開發環境跑得動，不代表在真實使用者手上、真實資料量、真實操作習慣下也跑得動。直接全面開放，第一批客人就成了測試者，而且是會留下負評、不會再回來的那種。

封測、公測與試營運，就是在全面上線前，用逐步擴大的範圍讓系統接觸真實世界。範圍可控，出了問題的影響就可控；回饋收得到，修正就有方向。

這篇說明三種階段的差別、怎麼招募測試者、怎麼收集與分級問題、什麼時候可以正式上線，以及萬一上線後出狀況，怎麼退回安全的狀態。

封測、公測、試營運：三個階段的差別

這三個詞常被混用，但用途不同。用範圍與目的來區分最清楚：

階段	參與者	主要目的	常見形式
封測（封閉測試）	邀請制、少數人	找出功能錯誤與流程卡點	內部同仁、熟客、合作夥伴
公測（公開測試）	開放申請或公開下載	驗證不同裝置、使用習慣與負載	標示 Beta 的公開版本
試營運（軟上線）	真實客人，但範圍受限	驗證營運流程與客服、物流、金流	限定地區、時段、會員或品項

並不是每個專案都要三個階段都走。內部後台系統通常封測完就可以上線；面對大眾的 App 或電商，比較適合封測加試營運；公測則適合使用者量大、裝置差異多的產品。

要注意：這些階段都在驗收之後。封測不是用來替代 QA 測試或業主驗收的，基本功能錯誤應該在軟體驗收測試（UAT）就被抓出來，封測要找的是「規格沒想到」的問題。

開始前先定義：這次測試要回答什麼問題

沒有目標的封測，最後只會收到一堆零散意見，不知道該怎麼判斷。開始前先寫下三件事：

1. 要驗證的假設：例如「第一次使用的人能不能不靠說明完成預約」「店員在尖峰時段能不能用平板快速核銷」。
2. 測試範圍：哪些功能開放測試、哪些先隱藏；用測試資料還是真實資料；是否涉及真實金流。
3. 結束條件：測多久、達到什麼狀態就進入下一階段（後面會詳細說明）。

如果產品本身是 MVP，這一步要和產品目標對齊，可以搭配MVP 開發指南一起規劃。

招募測試者：找對人比找很多人重要

測試者的組成決定你能找到什麼問題。只找內部同仁，會漏掉新手才會遇到的困惑；只找熱心粉絲，會得到過度正面的回饋。

建議的組成：

• 內部同仁：熟悉業務，能判斷規則對不對，適合第一輪。
• 實際目標使用者：符合主要客群輪廓的人，最能反映真實操作。
• 不同裝置與環境：舊手機、小螢幕、不同瀏覽器、網路較差的環境，各至少要有人覆蓋。
• 第一線人員：店員、客服、司機等實際操作後台或現場的人，他們最清楚例外狀況。

招募時要講清楚的事：

• 測試期間與大約需要投入的時間。
• 要他們做什麼：自由使用，還是照任務清單操作。
• 資料怎麼處理：測試資料會不會被清除、個資如何保護。
• 怎麼回報問題，以及會不會收到回覆。
• 如果有提供感謝禮，條件是參與測試與回饋，而不是要求給好評。

測試者人數不必多，重點是組成要涵蓋不同類型的使用者。與其一次邀請大量的人，不如分批：第一批修完明顯問題後，再邀第二批，避免同一個問題被反覆回報。

回饋收集：讓問題可以被重現、被追蹤

回饋管道設計不好，常見的結果是：群組裡一句「好像怪怪的」，沒有截圖、沒有步驟，開發團隊無從查起。

建議設立三種管道：

1. 問題回報表單：固定欄位，包含操作步驟、預期結果、實際結果、截圖、裝置與瀏覽器、發生時間。格式可以參考如何向廠商回報 Bug，簡化成測試者願意填的版本。
2. 任務式回饋：給測試者幾個具體任務（例如「請完成一次預約並取消」），完成後回答幾個簡短問題：哪一步花最久、哪裡不確定該按什麼。
3. 行為資料：在系統中加上錯誤記錄與使用行為追蹤，看到測試者沒說出口的卡點，例如在某一頁反覆返回。網站可以搭配GA4 設定指南中的事件追蹤。

回饋收進來之後：

• 指定一位負責人每天整理，去除重複、補問細節。
• 每一則都登錄到同一個問題追蹤清單，有編號、狀態與負責人。
• 對測試者回覆處理結果，即使是「這次不改」。被回覆過的測試者，下一輪更願意認真參與。

問題分級：不是每個問題都要在上線前修

封測一定會收到很多問題，關鍵是分級。建議用四級，並在測試開始前和開發團隊約定好每一級的處理方式：

等級	定義	範例	處理原則
致命	資料錯誤、金流出錯、個資外洩、系統無法使用	訂單金額計算錯、看到他人資料	立即修正，未解決不得上線
嚴重	主要流程無法完成，且沒有替代做法	某款手機無法付款	上線前必須修正
一般	功能有誤但有替代做法，或影響範圍小	篩選條件組合後結果不正確	評估後排入上線前或上線後
輕微	外觀、文案、操作建議	按鈕對齊、用詞不一致	列入改善清單

分級時常見的兩種偏差要注意：

• 把意見當問題：「我覺得顏色應該更亮」是設計建議，不是錯誤。可以收集，但要和需求範圍對照，屬於新需求的部分，走需求變更管理的流程評估。
• 把少數裝置的問題當作輕微：如果出問題的裝置正好是主要客群常用的，就不是輕微問題。分級時要考慮影響的人是誰。

什麼時候算可以正式上線：上線判斷清單

「感覺差不多了」不是上線標準。建議在測試開始前就定好下面這份清單，並由業主窗口和 PM 一起逐項確認：

品質條件

• 致命與嚴重等級的問題全部修正，並經過再次驗證。
• 一般等級問題都有決定：上線前修，或列入上線後清單並有預定時間。
• 最近一輪測試沒有出現新的致命或嚴重問題。
• 主要流程在目標裝置與瀏覽器上都跑過一次完整測試。

營運條件

• 客服知道怎麼回答常見問題，有處理流程與升級對象。
• 後台操作人員完成教育訓練。
• 金流、物流、通知等外部服務已切換為正式設定並實測。
• 若有既有資料要轉入，轉入結果已抽樣核對。

技術條件

• 監控與錯誤警報已開啟，知道誰會收到通知。
• 正式環境的備份已設定，並至少做過一次還原演練。
• 回退方案已寫好並確認可執行（下一段說明）。
• 上線當天與之後幾天，開發與維運有人可以即時處理。

網站的完整上線檢查可以搭配網站上線前檢查清單；App 則還要通過商店審核，事項整理在App 上架檢查清單。

回退方案：先想好怎麼退，才敢往前走

不論測得多完整，正式上線仍可能遇到測試期沒出現的狀況。回退方案的目的，是讓你在發生問題時有一條事先演練過的路，而不是在壓力下臨時決定。

回退方案要寫清楚的內容：

1. 觸發條件：什麼情況要啟動回退。例如出現致命等級問題且短時間內無法修正、主要流程大範圍失敗。
2. 決策者：誰有權決定回退。建議是業主窗口與技術負責人共同決定，並事先講好聯絡方式。
3. 技術步驟：怎麼退回上一版程式、資料庫要不要還原、新舊版資料怎麼處理。部署與版本退回的概念可以參考開發、測試、正式環境與部署白話解說。
4. 對外說明：要通知哪些人、用什麼管道、說什麼。先準備好公告的草稿。
5. 資料處理：回退期間產生的訂單或資料怎麼保存與補登，避免遺失。

降低回退需要的做法：

• 功能開關：新功能可以在不重新部署的情況下關閉，出問題時只關掉那一塊。
• 分批開放：先對一部分使用者或一個地區開放，確認穩定後再擴大。
• 新舊並行：重要流程保留舊做法一段時間，例如舊系統保持唯讀、人工流程備而不用。

回退不是失敗，是風險控制。事先講好回退條件，團隊在上線當天反而能更冷靜地判斷。

正式上線後：測試的節奏不要突然停掉

正式上線後的頭幾週，問題回報通常比封測期更多，因為使用者變多了、情境變雜了。建議：

• 保留封測期的回報管道與問題清單，不要換一套。
• 上線初期每天檢視錯誤記錄與客服回報，之後再逐步拉長間隔。
• 把上線後清單中的一般與輕微問題排入固定的改版週期。
• 回頭檢視一開始設定的假設，確認哪些被驗證、哪些需要調整。

結語：分階段開放，是給系統也給團隊一段磨合期

封測、公測與試營運不是拖延上線，而是讓系統、營運流程和團隊在可控範圍內磨合。先定義要驗證什麼、找對測試者、讓問題可追蹤、用分級決定優先順序、用清單判斷能不能上線、再準備好回退方案，正式上線就會從一場賭注變成一個有把握的決定。

NETVANA 在專案驗收之後，可以協助業主規劃封測與試營運的範圍、建立問題回報與分級流程、準備上線判斷清單與回退方案，也能在試營運期間提供修正與監控支援。軟體服務一律採詢問報價制，我們會依你的產品型態與上線時程提出測試規劃後再討論合作方式，歡迎與我們聯絡，或到軟體服務介紹了解服務內容。

延伸閱讀：封測之前要完成的驗收，看軟體驗收測試（UAT）指南；請測試者回報問題的格式，參考如何向廠商回報 Bug；App 上架前的準備，看App 上架檢查清單；網站上線前的檢查，看網站上線前檢查清單；用最小範圍驗證產品方向，看MVP 開發指南。