如果把軟體想成一座城市，商業區代表的就是那些「最值錢、最常用、也最不能出錯」的地方。
上一篇談到指南測試、Blogger’s Tour、Pundit’s Tour 與 Competitor’s Tour，重點是從文件、社群經驗、使用者抱怨與競品期待，重新理解商業區裡真正值得注意的風險。
但找到商業區，只是第一步。
接下來更重要的問題是：進入商業區之後，要怎麼逛？
你可以跟著產品最賺錢的賣點走，也可以沿著核心功能地標移動；可以刻意把系統推到極限，也可以像追物流一樣追著一筆資料跑；甚至可以等到深夜，看沒有人操作時系統自己在做什麼。當時間有限時，也可以像垃圾車巡街一樣，快速把整個區域掃過一遍。
這也是漫遊測試有趣的地方：它不是叫測試人員「隨便逛」，而是提供不同的探索視角，讓你用不同路線去看同一個系統。
Day 13，我們繼續留在軟體城市的商業區，看看六條很不一樣的探索路線：賣點測試、地標測試、極限測試、快遞測試、深夜測試，以及遍歷測試。
同一個產品，換一條路走，往往就會看到完全不同的風險。
(2) 賣點測試法
當我們談探索式測試的不同導覽路線時，有一條路線，切入點更直接，也更現實。它不問文件寫什麼，不問使用者怎麼學，也不問競品怎麼做。它只問一件事：公司是靠哪一段功能在賺錢？這就是所謂的「賣點測試法」（The Money Tour）。賣點測試法它是以產品最具商業價值與銷售說服力的功能為中心，驗證其流程穩定性、可展示性與任務完成可靠度。
這個方法之所以被提出，其實來自一個很直覺的觀察。如果你去一座城市旅行，你會發現某些地方特別熱鬧。人潮、資源、維運能量都集中在那裡，因為那些地方直接關係到城市的收入與形象。
軟體產品也存在同樣結構。使用者之所以願意購買、訂閱或持續使用，往往不是因為所有功能，而是因為某些關鍵特性能替他創造價值。這些特性，就是產品的賣點。
換句話說，這條路線測的不是「功能是否存在」，而是當使用者真正要為它付錢時，是否能順利完成。
在賣點測試法中，有一個常被忽略、卻極具價值的觀察來源：銷售人員。銷售人員每天都在示範產品，他們知道客戶最在意什麼，也知道該怎麼操作才能讓產品看起來最順，甚至會刻意避開某些不穩定流程。換句話說，他們手上的 demo 劇本，就是產品最核心的賣點路徑。
因此，測試者若想理解產品真正靠什麼在成交，觀摩銷售示範往往比閱讀需求文件更直接。
下面我們用Google Calendar來當範例，看看可以如何應用賣點測試法：
範例 1：跨團隊會議自動排程
這是企業用戶最依賴的功能，也是 Google Workspace 展現其「整合力」以對抗其他排程工具的關鍵賣點。下面是可能的測試重點：
範例 2：多平台資源預約與視訊整合
對於企業來說，Google Calendar 不只是記事本，而是辦公資源調度中心。能流暢地「訂會議室」並「自動生成視訊連結」是留住付費客戶的關鍵。下面是可能的測試重點：
在這兩個範例中，我們不測試「更換日曆顏色」或「設定生日提醒」，因為那些功能雖然存在，但不是客戶決定「買單」或「續訂」Google Workspace 的主因。
(3) 地標測試法
在導覽式探索測試的眾多路線裡，地標測試法（Landmark Tour）是一種很容易被理解、也很容易上手的方法。
它的概念其實來自真實世界的移動經驗。當一個人走進陌生城市或森林時，很少有人會隨機亂走。多數人會先找出幾個明確可辨識的目標物——例如高樓、橋樑、雕像、車站。這些地標能幫助人確認方向，也能讓人逐步接近目的地。
探索式測試裡的地標，指的也是同樣概念：系統中那些最顯眼、最核心、最不可能被忽略的功能節點。測試者不會從邊角開始，而是先鎖定這些關鍵位置，然後從一個地標移動到另一個地標，逐步探索系統全貌。所以地標測試法可以理解為：先辨識系統中的核心功能節點，並以這些節點為導航點，串連探索與測試路徑。
它不像指南測試那樣依文件走，也不像賣點測試只盯成交流程，而是透過「關鍵功能分布」來建立探索地圖。重點不在單一功能，而在地標之間的連結關係。
我們用Facebook 當範例來做說明。若把 Facebook 想成一座城市，地標其實非常明顯。大多數使用者每天打開 FB，幾乎一定會經過幾個地方：
這些就是 FB 的地標。
不管使用者最終目的為何，滑動態、回訊息、發照片幾乎都會穿越其中幾個節點。
場景一、從一個地標走到另一個地標
採用地標測試法時，測試者不會隨機操作，而是刻意設計「地標跳躍路線」。
例如從動態消息開始。你先滑動動態消息，看到朋友發文後按讚，接著點進留言區留言，再點進對方個人頁，從個人頁進入 Messenger 傳訊息，最後回到通知中心確認互動提醒。這條路線其實就是一條典型使用者動線。
測試者會觀察以下事情：
問題往往不在單一功能，而在地標之間的銜接。
場景二、多地標覆蓋的測試策略
地標測試的價值，在於它能逐步擴展覆蓋範圍。例如測試者可以設計不同起點：
每一次跳躍，都是一條新的探索路線。
透過記錄已走過的地標與路徑，測試者能建立一張「功能覆蓋地圖」，確保核心區域都被串連檢視。
為什麼地標測試特別有效？因為它避免了兩種常見盲點。
地標測試則介於兩者之間，有方向，但不僵化；有結構，但保留探索彈性。當測試者能清楚描繪這張地標地圖時，他測到的就不再只是功能是否存在，而是使用者每天實際走過的那條路，是否真的順暢無阻。
(4) 極限測試法
在軟體測試方法裡，極限測試法（Intellectual Tour）是一種典型的探索式測試技巧。它的出發點是去問一個尖銳的問題：如果把系統推到極限，它還撐得住嗎？很多缺陷不是出現在正常操作下，而是發生在邊界、極端情境或設計上限附近。極限測試，就是專門往這些地方去挖。
什麼叫「極限」？所謂極限，通常包含幾種面向：
這是刻意思考：系統的設計假設是什麼？哪裡最可能承受壓力？
我們用 Google 首頁當範例。Google 首頁看起來極度簡單，一個搜尋框、一個按鈕。但正因為簡單，更容易拿來示範極限測試的思維。
A. 搜尋字數的極限
一般人搜尋，大概幾個字到十幾個字。那如果輸入 8,000 個字？貼上一整篇論文？混入大量特殊符號？
這時確認的是需不需要有限制輸入長度？送出後是否延遲明顯？URL 參數是否過長？會不會回傳 500 錯誤？這是在檢查輸入處理與穩定度。
B. 特殊字元與編碼邊界
再換個角度。如果輸入連續 200 個 Emoji、混合各種 Unicode 字元、或是含有 或其他可疑字串。
這時你測的是編碼轉換是否正確、是否有 XSS 或解析問題、結果頁是否顯示異常。這種極限測試，往往和安全性高度相關。
C. 操作頻率的極限
如果同一個使用者每秒搜尋 10 次，同時開 30 個分頁搜尋，並且長時間連續操作。
這會測出是否有流量限制機制，系統需不需要判定它是機器人，系統的回應是否變慢或不穩定。這屬於壓力與防護能力的極限。
從上面範例可以知道，一般功能測試在確認功能符合規格，而極限測試在確認系統在非典型情境下是否穩定。它幫助團隊回答一個關鍵問題：系統的設計能力，和實際實作能力，是否一致？尤其在高流量網站、電商平台、金融系統等場景，極限測試往往比單純流程測試更有價值。
(5) 快遞測試法
在談各種軟體測試方法時，很多人習慣聚焦在功能對不對、畫面有沒有顯示正確。但在真實系統裡，真正容易出問題的，其實是「資料」。這也是快遞測試法（FedEx Tour）存在的價值。
它的概念來自物流業：一個包裹從寄出、轉運、分流、再配送，最後到收件人手上。過程中，每一站都會掃描、更新狀態、留下紀錄。如果哪一站出錯，包裹可能就消失了。
在軟體系統中，資料也是這樣流動的。快遞測試法強調的不是單一功能，而是一筆資料從輸入開始，到最後被使用或輸出，中間經過了哪些地方？所以快遞測試法要追蹤的重點，是追蹤資料的生命週期。
測試人員要做的，是像物流追蹤一樣，一站一站檢查：資料是否正確接收、是否被正確儲存、或者是否被其他模組使用、以及最後是否正確呈現。
這種方法特別適合高風險系統，例如訂票系統、金流系統、會員系統。因為這些系統一旦資料錯亂，影響的不只是顯示，而是交易本身。
這裡我們用台灣高鐵訂票系統當範例，資料流動其實非常清楚：使用者輸入資料 → 系統驗證 → 建立訂單 → 扣除座位 → 付款 → 查詢 → 修改或取消。每一個動作，都是資料在移動。以下幾個例子，可以清楚看見快遞測試法的實際操作方式。
範例一：身分證字號的資料旅程
當使用者輸入身分證字號完成訂票時，這筆資料就像一個包裹進入系統。
第一站是輸入驗證。格式是否正確？英文字母大小寫是否會被轉換？錯誤時是否給出明確提示？
接著它會進入資料庫，與訂單綁定。這時候要確認儲存格式是否一致，是否出現截斷或編碼錯誤。之後，這筆資料還會被用在：查詢訂票、取票驗證、取消訂單、和客服查詢等地方。
快遞測試法的重點在於：這筆身分證資料在不同模組之間流動時，有沒有被改變？有沒有某一站處理方式不同，導致查不到訂單？
範例二：座位數量與庫存扣減
再看訂票張數。假設使用者一次訂 4 張票。這個數字不只是顯示在畫面上，它會影響庫存、訂單金額、付款金額、取消後回補座位。
這筆「數量資料」會影響到的地方包括：輸入階段是否限制最大張數、建立訂單時是否即時扣減庫存、不同使用者同時訂票是否發生競爭條件、以及取消訂單後是否正確回補。
快遞測試法會讓測試人員刻意去追蹤這個數字在每一站的變化，而不是只看「畫面顯示 4 張」。
所以快遞測試法提供的是另一種視角：把資料當成包裹，一路追蹤到終點。當你開始用這種方式思考，你會發現很多真正嚴重的缺陷，都藏在資料流轉的細節裡，而不是按鈕壞掉那麼簡單。
(6) 深夜測試法
在軟體測試方法裡，很多人把焦點放在白天的操作流程：搜尋是否正常、按鈕是否可點、付款是否成功。但真正容易出大事的，往往不是白天，而是深夜。
所謂深夜測試法（After-Hours Tour），就是刻意去觀察與驗證：當系統進入非高峰、非營業、或自動批次運作的時段時，它是否仍然穩定可靠。換句話說，它不是測「人怎麼操作」，而是測「系統自己怎麼運作」。
白天有使用者操作，流程清楚，畫面可見；但到了深夜，很多系統會啟動背景功能，像是跨日邏輯重算、批次清算、庫存回補、報表產生或是系統重啟與維護等等。如果時間判斷或邏輯條件寫得不夠嚴謹，問題只會在特定時間點出現。
這裡同樣使用台灣高鐵訂票系統當範例，這個系統是一個典型的時間敏感系統。車票有日期、時段、付款期限、取消規則，還有座位庫存管理。只要跨日或批次處理出現錯誤，就可能影響交易與乘客權益。
例子一：午夜批次取消與座位回補
許多訂票系統會在深夜清理「未付款訂單」。例如訂票後 30 分鐘未付款，系統會自動取消並回補座位。
假設一筆訂單在 23:50 建立，00:10 批次程式啟動。此時需要追蹤：這筆訂單是否正確被判定為逾時？座位是否回補到庫存？如果使用者在 00:05 完成付款，批次程式是否正確辨識已付款狀態？
這裡常見的風險是時間競爭條件。付款與批次清算同時發生時，如果鎖定機制或狀態同步設計不夠嚴謹，就可能出現：已付款卻被取消，或是座位重複釋放，導致訂單狀態不一致，這些都是典型的深夜問題。
例子二：系統重啟與排程任務
訂票系統通常會在凌晨進行維護或重啟。重啟之後，系統是否正確恢復狀態，是另一個關鍵。
例如：未完成的訂單是否保留？登入中的使用者是否安全登出？排程任務是否重複執行？如果排程任務在重啟後被觸發兩次，可能會產生重複扣款或重複取消的情況。
此外，報表與銷售統計通常在深夜產生。如果日期計算出現閏年或跨月處理不當，統計資料就會失準。這些錯誤不會在白天出現，但影響卻非常真實。
很多重大缺陷，不是在白天的功能測試中被發現，而是在凌晨兩點，系統自動運作時暴露出來。測試不只是模擬使用者行為，有時候，更重要的是模擬「時間本身」。
(7) 遍歷測試法
在軟體測試方法中，很多人一開始學的都是深入測試：針對某個功能寫完整測試案例、驗證邏輯、檢查邊界條件。但在實務上，還有一種同樣重要的技巧，叫做遍歷測試法（Garbage Collector’s Tour）。
這個名稱來自一個很生活化的比喻。垃圾車每天依固定路線巡街，一戶一戶收垃圾。它不會在某一戶門口停很久，也不會仔細檢查垃圾內容，但它會確保整條街都走過，不會漏掉任何一戶。
遍歷測試法的精神，就是這樣。它強調的不是深入，而是全面與覆蓋。它是有計畫地走過整個系統。選定一個範圍或目標，設計一條有效率的路徑，快速走過系統中的所有相關區域，確認沒有明顯問題被遺漏。
這種方法特別適合用在：新版本上線前的整體巡檢、接手陌生專案時的初步理解、和大幅改版後的健康檢查等場景。它的目的不是找出最細微的缺陷，而是先確認系統沒有「破洞」。
接下來用 LINE 當範例，來看看怎麼做遍歷測試？LINE 是一個功能龐大的 App。聊天、社群、通話、貼圖商店、錢包、設定頁面，入口多、互動複雜。如果每個功能都要深入測試，時間往往不夠。這時候，遍歷測試就很有價值。
你會先問自己一個問題：我要巡哪一條「街」？目標不同，巡檢路線也會不同。
例子一：完整走過主要功能入口
假設今天的目標是確認「主要入口是否都正常」。那麼你可以設計一條路線：從 LINE 主頁開始，依序點擊聊天、社群、通話、錢包、設定，並在每個區域隨機進入一個子功能。
這個過程中，你不會花很多時間測聊天排序演算法，也不會測貼圖購買流程的所有邊界條件。你只是觀察：
頁面是否能順利開啟？
畫面是否有明顯錯位？
是否出現閃退或載入卡住？
是否有功能按鈕失效？
這種遍歷方式的重點在於「整體健康度」。如果某個區塊因為改版導致入口失效，遍歷測試很快就能發現。
例子二：以「聊天功能」為主題的全面巡走
另一種做法，是鎖定一個模組，例如聊天功能，然後走過所有常見操作。你可以打開一個一對一聊天，傳送文字、貼圖、圖片，再切換到群組聊天，試著標記成員、查看成員列表、搜尋聊天記錄。這不是深入測試貼圖渲染效能，而是確認整個聊天操作鏈都能順利運作。
在改版後，常見的問題不是核心邏輯錯誤，而是某個選單連結斷掉，或某個按鈕點了沒反應。遍歷測試正是用來抓這種問題。
遍歷測試法提供一種有效率的方式，在有限時間內快速掃描整體狀況它特別適合敏捷開發節奏下的版本巡檢。對於想提升探索式測試能力的人來說，遍歷測試是一種非常實務、也非常必要的基本功。
在大型 App 測試、探索式測試實務、版本健康檢查中，遍歷測試法是一種簡單卻非常有效的策略。有時候，品質不是藏在深處，而是藏在你沒走到的地方。
iThome鐵人賽
看影片追技術