在 《#064 專案上線的溝通密碼》 我們把版號規則講清楚了，在 《#065 上線前的最終試煉場》 也把 DEV、QAT、UAT 與 PROD 的環境角色區分開來。等到程式碼部署進測試環境之後，很多 PM 會有一種鬆一口氣的感覺，覺得終於可以開始「測測看」了。
問題是，測試從來不是到處點一點、看起來沒壞就算過關。不同的環境、不同的版本規模、不同的功能性質，本來就應該搭配不同的測試策略。若沒有一套明確的方法，測試很快就會失去重點，而且沒有效率也浪費時間。工程師覺得你回報的問題都只是表面現象，真正有問題的漏洞卻一路留到正式環境，最後由真實用戶替你驗證，然後客服的電話馬上就會被打爆，PM的LINE訊息也會響到隔天太陽起床。
這篇文章想聊聊的，就是 PM 該看待「測試」這件事。PM 當然不是測試人員，也不應該需要寫測試程式，但你必須知道怎麼判斷測試深度、怎麼安排測試節奏，以及怎麼把關交付品質。
◆ 測試的兩個視角。黑箱測試與白箱測試
在軟體開發裡，最常被提到的兩種測試視角，就是黑箱與白箱。PM 不需要親自執行白箱測試，但你必須知道兩者之間的分工邊界。
白箱測試（White-box Testing）
白箱測試處理的是程式碼內部邏輯是否正確。例如條件判斷是否完整、迴圈是否有問題、演算法是否有漏洞、例外狀況是否被妥善處理。這一層通常由 RD 在開發階段透過單元測試或其他工程手段先行把關。它關注的是程式碼「裡面」有沒有問題。
黑箱測試（Black-box Testing）
黑箱測試則是 PM 與 QA 的主戰場。它不是看程式碼怎麼寫，而是把系統當成一個黑盒子，只觀察輸入與輸出之間是否符合預期。也就是說，我們不關心裡面用了哪一個演算法，而是關心「輸入 A，是否真的得到預期的結果 B」。
PM 在這裡的責任，不是替工程師補做白箱測試，而是確保黑箱測試足夠接近真實使用情境。換句話說，PM 不必進到程式碼裡，但必須確認團隊在交付前，既做過基本的白箱把關，也做過符合規格與情境的黑箱驗證。
但是，在現實開發裡，有一個隱藏陷阱PM必須知道，很多時候RD會很仰賴QA的黑箱測試，透過黑箱測試的結果符不符合預期，來回推程式碼有沒有邏輯上的問題。於是很多時候的爭吵就會在這邊發生，以QA的視角來看，很多基本的邏輯上的問題，應該在RD交付前就可以自己先測過，不需要到QA這邊才發現，然後退版；以RD的視角，往往在專案時程壓力下，並沒有足夠的時間可以做足白箱測試，只簡單的測測功能流程是否正常，於是能運作就交給QA進行測試。最後就會變成雙方的不諒解，這在軟體開發過程中很常出現的陷阱。請務必在RD開發過程中，可以在時程內盡量爭取可以讓RD進行白箱測試的時間。
◆ 測試不是只有一種深度。功能性、壓力與破壞性，看的不是同一件事
很多團隊做測試時，只測流程順利的情況。這當然必要，但遠遠不夠。尤其到了 QAT 與 UAT 階段，如果只檢查 Happy Path，正式上線之後，真正會造成傷害的問題通常還是會留下來。
一般來說，測試深度至少可以分成三個層次。
功能性測試（Functional Testing）
這是最基本的底線。註冊能不能成功、購物車能不能結帳、密碼輸入錯誤時是否有正確處理、權限不足時是否能被擋下。它驗證的是規格書裡定義好的 Happy Path，以及可預期的例外情境。這一層如果沒有先過關，後面的測試就沒有意義。
壓力測試（Stress / Load Testing）
系統平常運作正常，不代表高峰期也能承受。壓力測試的目的，就是模擬大量使用者同時湧入，例如搶購、活動報名、限時結帳等情境，觀察系統在高壓條件下的穩定度，包括 CPU、記憶體、資料庫與 API 回應時間是否出現異常。這類測試通常由工程團隊執行，但 PM 不能因此缺席。因為系統要承受多大的流量，本質上是業務預期，而不是單純技術數字。每秒 500 筆訂單、同時 3000 人登入，這些條件都需要 PM 協助界定。
破壞性測試（Destructive Testing）
這一層測的，不是系統會不會順利完成任務，而是當使用者操作極端、異常，甚至帶有惡意時，系統會如何反應。名字欄位輸入 5000 個字、金額輸入負數、上傳一個異常格式的大型檔案、在網路不穩定時連續按兩次送出。這些情境不一定每天都發生，但只要發生一次，系統若處理不當，往往就是正式環境裡最具破壞性的問題。
因此，測試不是只有「有沒有BUG」，而是要先釐清你現在測的是什麼東西？目標清楚了，你也才能安排對應的「測試計畫」。
◆ 依據版號規模，決定測試範圍
這裡就會直接連到 《#064 專案上線的溝通密碼》 談過的版號規則。因為測試不能每次都從頭到尾全部重做，那樣的成本太高，也不符合實際節奏。測試的範圍，應該跟著版本規模調整。
大版本（Major）
當版號進到大版本，通常代表底層架構、核心流程或重要介面有明顯變動。這種情況下，不能只測新增功能，而必須啟動完整測試計畫，並進行回歸測試。原因很簡單，新的架構或流程，很可能同時影響舊功能。若沒有把既有功能一起驗過，正式上線後很容易出現「新功能正常，但舊功能失效」的情況。
中版本（Minor）
中版本通常代表系統新增了新的功能模組，例如新付款方式、新報表、新管理功能。這時候測試的重點，應該放在新功能本身，以及與它有直接關聯的舊模組。例如付款方式擴充，不只要測新支付流程，也要重新確認訂單、退款、發票與通知這些相關環節是否仍然成立。
小版本（Build）
小版本多半是 Bug 修正或細節調整。這類版本不需要每次都重做全站測試，但也不能因為「只是修一點東西」就完全放過。此時比較合理的做法，是做重點確認，也就是先驗證原本的問題是否已經修正，再確認周邊關聯功能沒有受到影響。
PM 若能依版本規模安排測試範圍，團隊的時間就不會浪費在不必要的全面檢查，也比較不會因為測試過度樂觀而漏掉真正有風險的地方。像以前在進行遊戲開發專案時，會每週固定一段時間進行版本更新與資料備份，如果這次的版本是要更新大的系統，為了確保系統穩定度，多半會規畫半天甚至是一天的更新流程，如果只是更新一些BUG，則可能在2-3小時就完成，並不需要全面性地進行測試。
◆ 測試前要先準備好。測試計畫與測試案例不是形式，而是基本盤
很多團隊的測試方式很像臨場反應。想到什麼就測什麼，看到哪裡就按到哪裡。這種方式偶爾可以抓到問題，但無法形成穩定的交付品質。
在進入 QAT 之前，至少應先準備兩份東西。
測試計畫（Test Plan）
這是一份大方向的安排文件。這次要測哪些範圍、不測哪些範圍、由誰執行、在哪個環境測、時程如何安排、是否需要特殊帳號、假資料或特定權限。測試計畫的價值在於，它能先把邊界畫清楚，避免所有人都以為「有人會測」。
測試案例（Test Cases）
這是具體的執行劇本。要把規格拆成一條一條明確的步驟與預期結果。
例如，在未登入狀態下點擊付費文章，預期應跳出「請先登入」提示，並導向登入頁。
你把步驟與結果寫清楚，驗收才有標準，也不會因為換一位測試者就漏掉某些情境。
很多 PM 會低估這件事，覺得只要大家都知道要測什麼就好。問題在於，專案現場最常發生的，不是大家不知道功能，而是大家以為別人測過了，BUG往往就出現在這樣的細節中。
◆ 抓到 Bug 之後，先判斷前端還是後端，問題鎖定會快很多
在 《#061 PM 不用會寫程式碼，但要懂的技術架構》我們已經談過前端與後端的分工。到了測試階段，這個概念會變得非常實用。因為 PM 若能初步判斷問題比較接近哪一邊，整個溝通效率會明顯提高，也比較不容易出現彼此推託的情況。
PM 不需要會寫程式碼，但可以學會看瀏覽器的開發者工具，特別是 Network 標籤。
第一種情況，按鈕按下去之後，Network 裡根本沒有送出請求。這通常表示前端流程就已經被擋住，例如驗證邏輯、按鈕狀態或事件綁定出現問題。
第二種情況，請求有送出，但回傳的是 500 類型的錯誤。這通常代表問題在後端，因為伺服器在處理請求時發生了異常。
第三種情況，API 回傳成功，資料本身也正確，但畫面顯示錯誤、資料位置不對，或畫面沒有更新。這通常比較接近前端顯示層或畫面更新邏輯的問題。
只要 PM 能掌握這三種最基本的判斷方式，回報問題時就不會只剩下一句「畫面沒出現」。你可以更明確地說明，是請求沒送出去、後端回傳錯誤，還是畫面顯示與資料內容不一致。這種清楚程度，本身就會大幅提升專案溝通品質。
◆ Bug 回報的核心，不是抱怨，而是重現路徑
「工程師，購物車壞了。」這種回報方式在現場很常見，但對工程團隊幾乎沒有幫助。因為對工程師來說，不能重現的 Bug，就幾乎等於無法處理的 Bug。
所以，一份合格的 Bug 回報，最重要的不是情緒，而是重現路徑。
你至少要交代幾件事。
環境與載體
問題發生在 QAT、UAT 還是 PROD。
是 iOS、Android、Web，內網還是外網，4G還是Wifi。
瀏覽器與裝置版本是什麼。
測試帳號
你用的是哪一個帳號、哪一種權限。有些問題不是所有人都會遇到，而是特定權限或特定資料狀態才會出現。
操作步驟
第一步點了什麼，第二步輸入了什麼，第三步在哪裡出現異常。
步驟若不清楚，工程師往往只能從頭猜。
實際結果與預期結果
系統實際出現了什麼。
而規格原本期待它應該呈現什麼。
這兩者一旦對照清楚，問題才真正有辦法被定義。
附件
截圖、螢幕錄影、錯誤訊息，能附就附。
因為很多畫面問題，不是靠文字三言兩語就能講清楚。
把重現路徑寫清楚，不只是提高修正效率，也是對工程團隊最基本的專業尊重。
◆ 容易被忽略的測試條件，往往才是正式環境裡真正的地雷
很多系統在辦公室測試時運作正常，一進正式環境給外部使用者使用，問題就開始接連出現。這不是因為正式環境比較難，而是因為你忽略了現實情境本身就不同。
內網與外網的差異
在公司內部用穩定網路測試，和外部用戶在 4G、5G 或不穩定 Wi-Fi 條件下操作，本來就不是同一件事。圖片載入過慢、API 逾時、重試機制異常，很多問題只在外網情境下才會浮現。
快取問題
工程師常說「清一下快取就好了」。但真實世界裡，你不能把清快取當成預設解法。因為正式用戶不會在每次看到異常畫面時，都知道要去清瀏覽器或 App 快取。若系統更新後仍持續讀到舊資源，正式環境出現的就不是操作問題，而是版本與資源管理問題。
跨裝置與跨瀏覽器
不要只用桌上的新機與 Chrome 測。舊手機、不同作業系統版本、Safari 或其他瀏覽器，常常會直接暴露另一批問題。你不一定要做到全覆蓋，但至少不能假設「我這台可以」就等於所有用戶都可以。
CDN 與跨區網路環境
還有一種情況，在台灣團隊的測試裡很容易被忽略，就是 CDN 加速。很多產品為了提升載入速度，會把圖片、前端資源或靜態檔案放到 CDN 上，理論上這樣做沒有問題，甚至在多數情境下會讓體驗更順。但如果你的目標客戶在中國大陸，CDN 有時反而會變成一個不穩定因素。
原因不在於系統本身壞掉，而在於不同地區的網路路徑與資源傳輸條件並不一致。從台灣或其他地區測試時看起來很順的資源，在中國境內實際連線時，可能就會出現載入緩慢、部分資源取不到、畫面時好時壞的情況。這類問題麻煩的地方在於，辦公室裡通常測不出來，開發環境也看不出來，只有在當地真實網路條件下才會現形。
實務上，若產品確實要服務中國大陸的使用者，很多時候就不能只依賴原本的 CDN 設計，而需要進一步評估是否改用中國境內的雲服務或更適合當地網路條件的資源分發方式。要發現這類問題，最有效的方法不是在會議室裡推測，而是要有一位身處中國境內的夥伴，用當地真實的網路環境實際連線、實際操作、實際驗證。也正因如此，UAT 的價值才會真正顯現。因為它驗證的，不只是系統功能是否成立，而是系統在真實使用者所在的環境裡，能不能穩定運作。
很多正式環境裡的重大問題，不是因為邏輯太複雜，而是因為測試條件太理想。
◆ 廣三觀點
嗨，我是廣三。
很多 PM 會覺得測試是一件繁瑣、重複、甚至有點消耗的工作，好像那是 QA 的責任，和自己沒有太直接的關係。但實際上，測試策略本來就是產品交付前最重要的一場沙盤推演。
你怎麼安排測試計畫，怎麼界定回歸測試範圍，怎麼判斷大版本與小版本該有不同測法，這些事情看起來不像產品設計，卻都直接影響產品能不能平穩進入正式環境。當你能系統化整理測試案例，能初步區分前端與後端問題，能把 Bug 的重現路徑說清楚，你其實不是在單純抓蟲，而是在替整個專案的交付品質保留最後一道緩衝。
我一直很在意一件事，在 QAT 與 UAT 多花一點時間，不是浪費，而是在替正式環境減少付出的代價。測試若沒有策略，正式環境就會幫你上一堂系統掛掉的課。而這件事，通常都會讓團隊沒辦法回家睡覺。
若你在PM這條路上感到迷茫，
或想更清楚了解自己的能力與定位，
歡迎試試這份《PM產品／專案雙軌分析報告》。
它不為了定義你，而是幫助你更看清自己。
歡迎關注：
官網：https://unityprosper.com/
部落格：https://hero-mi.com/
FB：https://www.facebook.com/DigiPRDCoachHeroMi
LINE OA：@hero-mi
《歡迎加我LINE，一起破局未來》
請於下方輸入電子郵件信箱，即可接收最新訊息。
探索更多來自 AI時代|PM破局未來 的內容
訂閱即可透過電子郵件收到最新文章。
留言