國家選擇欄位測試：下拉、搜尋與排序

國家選擇欄位測試常常只做到「點得開、選得到」就結束，但它其實是整個表單裡最容易出事的一環：項目多、寫法雜、還要同時服務滑鼠、鍵盤與螢幕閱讀器。更麻煩的是，選完之後的連鎖影響往往比選擇動作本身大得多。以下把這個控件拆成幾個可分別驗證的部分。

國家下拉有幾種常見形態?

同樣叫下拉，實作方式與風險卻完全不同。形態選錯，後面所有的測試點都會跟著不同，因此第一步是先把形態認清楚。

每種形態都有它真正的失敗樣態。長清單的失敗是使用者找不到，可搜尋的失敗是打了半天沒結果，分組的失敗是項目被藏在收起來的群組裡，只列支援範圍的失敗是使用者以為資料錯了。測試時要針對這些失敗樣態設計，而不是只確認選項存在。

還有一個跨形態的問題：當清單來源與即時查詢並存時，兩者的內容必須一致。常見的錯誤是即時查詢能看到某個項目，靜態清單卻沒有，於是同一個地方在不同路徑下有的選得到、有的選不到。

這個問題的根源通常是兩份清單各自維護。比較穩健的做法是讓兩者都讀同一份來源，即時查詢只負責排序與過濾，不負責新增或刪除項目；這樣兩邊的成員集合就永遠一致，也不必靠人工定期比對。

真實使用者不會只打一種寫法。至少要能命中以下幾類，而且每一類都要有對應的測試樣本：

只對其中一種成功，等於對其他使用者失敗。這裡的關鍵不是要求模糊比對做得多聰明，而是要求「打得到的寫法」是被明確列舉並被測試過的；否則每次有人回報搜不到，都只能個案處理。

搜尋還有一個容易漏掉的邊界：完全比對與部分比對的優先順序。當輸入同時符合多個項目時，排序結果會決定使用者按下去的是哪一個。這條規則如果不明確，就會出現「同一串字今天選到 A、明天選到 B」的情況。

排序規則也要能被解釋。當使用者問「為什麼這個項目排在前面」時，團隊應該有一致的答案，而不是每次都重新推測。把規則寫下來，也讓日後調整排序時知道會影響哪些既有的使用習慣。

代碼相關的體系分工可以對照國家碼與下級行政區代碼那篇，本篇只談它在選擇控件裡該怎麼被搜到。

清單的排序看起來是小事，但它直接影響使用者能不能用「首字跳轉」快速找到目標。如果在某一種語言裡，帶變音符號的字被排到很後面，熟悉該語言的使用者就會一直找不到。

排序應該按目標語言的排序規則，而不是按字元編碼順序。這一點在清單很長、又沒有搜尋功能時尤其明顯。實務上常見的錯誤是全部按同一套規則排，只有在某一種語言下看起來正常。

分組的情況下還有兩個附加要求。第一，群組本身的順序也要合理；第二，用來收容不屬於任何群組的項目那一組必須是可達的，不能因為摺疊而消失。這一組往往是使用者最後的依靠，一旦被藏起來，他會直接放棄。

只測滑鼠操作是不夠的。當清單有幾十個項目時，鍵盤操作往往是重度使用者的主要路徑，而它也是最容易被忽略的部分。

虛擬化是另一個要專門測的點。為了效能而只渲染可見範圍時，很容易出現「畫面看得到、鍵盤卻到不了」的狀況，因為那些項目其實還沒被建立。測試時要刻意用鍵盤走到清單的頭尾，而不是用滑鼠捲動。

朗讀的內容也值得逐一確認。它應該包含目前選中的值、目前的群組，以及項目數量是否會在過濾後改變；只念出一個代碼而沒有名稱，對多數使用者沒有幫助。

選好之後才是問題的開始。切換到另一個地方時，原本的省州、城市與郵遞區號就未必還成立，而舊值如果留下來，會以一種看起來合法的姿態通過驗證。

需要處理的通常有三類：必須清空的、必須重新查詢的，以及必須重新驗證的。三類要分開決定，因為它們的處理方式不同——清空會影響使用者輸入的意願，重新查詢會影響效能，重新驗證則會影響錯誤訊息的呈現時機。

也要考慮使用者按返回鍵或重新整理的情況。狀態若只存在記憶體裡，重整之後可能出現一半是新選擇、一半是舊值的混合狀態，這種情況最難重現，也最難解釋。

選擇控件的核心原則是顯示與儲存分開。具體可以這樣落實：

下拉選項、搜尋關鍵字與使用者輸入的示例都是編造出來的合成資料，並非真實提交紀錄，也不代表任何真實目錄的排序結果或使用者行為統計。選完之後的連鎖影響與切換流程，可以接著讀跨境地址場景；而國家軸與語言軸為什麼不能互相推導，見國家與語言的區別。

先把你的選擇控件歸到上面某一種形態，然後針對那個形態的失敗樣態各寫一條測試。接著到國家與地區目錄實際操作一次，確認搜尋、排序與分組在你手上都走得到。