在軟體測試的實務現場，有一種很容易被忽略、但其實極其重要的思維，叫做歷史區測試（Historic District Testing）。所謂「歷史區」，就像城市裡的老城區。那些地方建築年代久遠、翻修多次，有些外牆重新粉刷過，但裡面可能還是舊結構。看起來穩定，實際上風險不小。

軟體系統也是如此。很多問題，不是出在剛寫好的新功能，而是出在那些已存在多年，被修補過無數次，有可能原始作者早已離職，並且文件不完整的老模組。歷史區測試的核心精神，就是刻意把注意力放回這些區域，而不是只盯著新功能。

歷史區測試是一種風險導向的測試方法。它的邏輯很務實：曾經出過問題的地方，很可能還會再出問題。測試人員不是平均分配時間，而是根據缺陷紀錄、修改歷史、版本變更紀錄，找出「高風險區域」，優先驗證。這種方法特別適合大型平台，例如 Facebook 這種功能龐大、長期演進的產品。

(1) 惡鄰測試法

在探索式測試方法中，有一種非常務實、也非常貼近現場經驗的技巧，叫做惡鄰測試法（Bad Neighborhood Tour）。

每個城市都有一些「問題比較多」的區域。當地人都知道，那裡交通混亂、事故頻繁、設施老舊。旅遊手冊會提醒你小心，但真正負責治安的人反而會更常巡邏那一帶。

軟體系統裡，也有這種「惡鄰」。惡鄰測試法指的是：針對過去曾大量出現缺陷、邏輯複雜或經常被修改的模組，加強測試。它的核心假設很簡單：缺陷會群聚。如果某個區域過去出過很多 bug，那代表它的設計可能複雜、條件判斷容易出錯，或者修改時容易影響其他模組。這樣的區域，就值得反覆檢查。惡鄰測試不是平均分配測試時間，而是把資源集中在高風險地帶。

LINE 作為大型即時通訊平台，功能龐大、歷史悠久，某些模組自然會成為「惡鄰」。以下幾個例子，可以幫助你具體理解惡鄰測試法如何運作。

例子一：隱私與封鎖設定

在 LINE 裡，封鎖與隱私權限一直是高風險區域。它包含：封鎖名單、
加好友權限、群組邀請、限時動態可見範圍等等。這些功能彼此交織，只要某次改版新增一個權限選項，就可能影響既有邏輯。例如：

• 使用者 A 封鎖了 B，但 B 是否仍能在共同群組中看到 A？
• 封鎖後是否還能搜尋到對方帳號？
• 封鎖與刪除好友是否有不同顯示結果？

如果這個模組在過去版本中曾多次修補缺陷，那麼每次改版，都應該重新回到這個區域驗證。這就是惡鄰測試的實際應用。

例子二：聊天訊息同步與多裝置登入

LINE 支援多裝置登入與聊天備份。這類功能通常架構複雜，而且歷經多次改版。假設某次更新優化了聊天介面，理論上不會影響同步機制。但實際上，舊的同步邏輯可能與新資料格式衝突。

測試人員在這種情境下應該刻意操作：
在手機與電腦同時登入
同步後刪除訊息
邊傳送邊切換網路
恢復備份後再同步

如果這個區域過去曾發生過訊息遺失或重複顯示的問題，那麼它就是典型的惡鄰。惡鄰測試法會要求你花比平常更多時間在這裡，而不是只測一次基本流程就結束。

惡鄰測試法會要求你刻意模擬各種異常狀況，例如：網路中斷、快速重複點擊、裝置切換、跨日交易。因為這些都是過去問題曾經出現的地方。

因為軟體不是理想狀態下設計完成，而是在現實中不斷修補。曾經出過問題的區域，代表它的設計存在某些脆弱點。即使問題修好了，脆弱性可能仍然存在。惡鄰測試的價值，在於利用歷史缺陷資料作為風險指標，而不是憑直覺猜測。

(2) 博物館測試法

在軟體測試方法中，有一種很有畫面感的技巧叫做博物館測試法（Museum Tour）。名字聽起來優雅，但背後其實帶著一點警告意味。

博物館裡陳列的東西，多半是古老、珍貴、甚至已經不再生產的物件。它們看起來安靜、安全，平常也沒什麼人碰，但只要保存不當、環境改變，就可能出現裂痕。

軟體系統裡也有這種「古董」。博物館測試法指的是：專門針對長期存在、很少改動、屬於遺留功能或舊程式碼的區域進行驗證。這些功能也可能很久沒有改版，原開發者已離職，單元測試覆蓋率低。它們不像新功能那樣受到高度關注，但一旦整體架構或周邊模組改變，最容易出現相容性問題。

Facebook 是一個長期演進的平台，從最早的動態牆、相簿、活動頁面，到後來的 Reels、Marketplace、社團、直播功能。新功能層出不窮，但老功能仍然存在。博物館測試法會是刻意回頭去操作那些「很少人再關心」的區域。

例子一：舊版相簿與早期上傳照片

Facebook 早期的相簿系統與現在的媒體處理機制並不完全相同。假設現在的圖片壓縮、標記臉部辨識、留言排序機制都已改寫，但十年前建立的相簿仍然存在。

博物館測試法會刻意去打開這些老相簿，檢查圖片是否正常顯示、標記功能是否仍可使用、留言排序是否混亂等等。這些老資料格式若與新版演算法不相容，就可能出現錯誤顯示或功能失效。而這種問題，只有刻意回頭測，才會被發現。

例子二：早期建立的粉絲專頁或活動頁面

Facebook 的活動頁面與粉絲專頁在多年來經歷多次 UI 重構。假設某個粉絲專頁建立於 2012 年，當時的資料結構與現在不同。

當新版介面上線後，博物館測試會檢查：舊頁面是否能正常編輯，舊活動是否能正常顯示報名狀態，或是早期設定的權限是否仍然生效。

(3) 上一版測試法

在軟體測試方法中，有一種非常基本卻常被忽略的策略，叫做上一版測試法（The Prior Version Tour）。很多團隊在改版時，重心都放在新功能上：新介面是否漂亮？新流程是否順暢？新演算法是否更快？但有一個問題往往沒人認真問：舊版本能做的事情，新版本還能做嗎？

上一版測試法，就是專門回答這個問題。上一版測試法指的是：以「上一個正式版本」為基準，確認新版本仍然保有既有功能與行為。它的核心精神其實很務實：產品可以進步，但不能退步。

這種測試不只是跑回歸測試清單，而是有意識地站在「老使用者」的角度，去操作那些他們已經習慣的功能，確保沒有被破壞。在大型平台中，這種方法尤其重要。因為改版越頻繁，越容易不小心砍掉一些原本就存在的能力。

軟體產品不像一次性商品，而是長期演進。每一次 UI 重構、架構優化或功能重寫，都可能改變底層邏輯。開發團隊可能覺得只是優化內部結構，但對使用者來說，只要某個熟悉的功能消失或行為改變，就是重大退步。

我們繼續用Facebook 來當範例，以下幾個例子，可以具體說明上一版測試法如何實際應用。

例子一：舊版貼文隱私設定是否仍然有效

假設舊版本的 Facebook 支援「自訂好友清單可見」的隱私設定。新版本改寫了隱私控制介面，看起來更簡潔。但上一版測試法會檢查過去已設定為「僅限特定好友」的貼文，是否仍然正確限制可見範圍？好友清單機制是否仍然存在？舊貼文在新版 UI 中是否能被正確編輯？

例子二：舊相簿與歷史照片的操作

Facebook 早期建立的相簿，可能使用不同的資料格式。當新版媒體系統上線後，上一版測試會去打開多年以前的相簿，驗證：舊照片是否仍能正常下載？舊標記功能是否仍然可用？留言排序是否保持一致？這種問題往往只影響少數老用戶，但對長期使用者而言，影響非常明顯。

回歸測試通常圍繞著最近改動的功能，確保修改不破壞現有邏輯。而上一版測試則偏向產品層面思考：它關心的是整體能力是否被保留，而不是單一程式碼是否正常。這兩者相似，但視角不同。上一版測試法提醒團隊：在追求創新的同時，不要忘記產品的歷史承諾。