說實話，很多人第一次聽到"本地化功能測試"這個詞時，腦子里想的都是："翻譯不是只要搞定文字就行了嗎？語言對了，軟件就能跑起來吧？"
真不是這么簡單。想象一下這個場景：你把一份中文菜譜翻譯成英文，單詞都對，語法也沒錯，但忘了把"攝氏度"改成"華氏度"，結果美國用戶按字面理解把烤箱調到200度——不是 Fahrenheit 的那種。軟件本地化測試干的就是防止這種事發生：不是看翻譯得漂不漂亮，而是得確認"翻譯"和"功能"在真實環境里能不能好好相處，會不會互相掐架。
在康茂峰這些年跟過的項目里，我發現真正意義上的功能測試，往往發生在翻譯公司把語言包交給客戶之后、正式上線之前的那段時間。它和普通的功能測試有點像，但又不完全一樣——你得帶著"跨語言"的視角去看問題。下面我就用大白話聊聊，這塊工作到底該怎么落地。
在康茂峰的內部流程里，我們管這叫偽本地化預測試（Pseudolocalization）。聽起來高大上，其實原理特別簡單：在真正開始翻譯之前，先讓工程師把軟件里的所有可提取字符串替換成"假的"目標語言——比如把 "Save File" 改成 "[?avē Fílé]"，加上一些變音符號和長度擴展標記。
為什么要這么干？因為這時候你會發現大量基礎問題：哪些文本是硬編碼在代碼里的（改不了）、哪些字符串被截斷了、哪些對話框放不下擴展后的文本。英語翻譯成德語，文本長度平均要膨脹30%到40%，有些巴西葡萄牙語的菜單項可能比英語長出兩倍。如果等到法語翻譯稿回來了才發現按鈕裝不下，回溯成本就高了去了。
這個階段其實不需要真正的譯者參與，主要是開發和測試團隊在跑。但在康茂峰的經驗里，本地化供應商最好提前介入，告訴客戶"哪些語言需要額外關注長度問題"。比如日語雖然字符多，但橫向占用空間其實比英語短；而泰語這種沒帶空格的語言，換行規則又完全不一樣。
等真正的語言包集成進去，第一件事是純視覺檢查。這時候你得把系統區域設置切到目標語言，像真正的用戶那樣從頭點到尾。
這是最肉眼可見的 bug。Windows 的對話框、iOS 的按鈕、安卓的 Toast 提示——這些地方經常會出現"保存"變成了"保"（后面被截斷），或者德語單詞 "Einstellungen"（設置）太長，直接溢出按鈕邊框。在康茂峰的處理規范里，我們會讓測試人員截圖標記所有截斷點，不僅僅是美觀問題，有時候截斷會導致功能性按鈕點不到。
如果你在做阿拉伯語或希伯來語版本，這事兒特別重要。這些語言是從右向左讀的，所以整個 UI 布局需要鏡像：滾動條要在左邊，前進/后退箭頭要互換，甚至進度條填充方向都要反過來。測試的時候不能只看文字對不對，得看布局邏輯有沒有跟著翻轉。我們曾經遇到過進度條文字是 RTL 了，但進度填充還是從左往右走的尷尬情況。
中文繁體的"裏"和"裡"、日文的漢字（有些跟中文寫法不同）、泰文的堆疊字符——這些在特定操作系統版本上可能會變成方框或亂碼。測試時要在最低支持的系統版本上跑，因為新系統通常字體庫全，老系統才可能缺字。
界面沒問題了，接下來得測深層邏輯。這里最容易踩坑的是格式處理和硬編碼字符串。
這簡直是重災區。美國習慣用 12/05/2024 表示 2024年12月5日，歐洲大部分地區理解為 2024年5月12日。小數點在美國是點（1.5），在德國是逗號（1,5），千分位分隔符又反過來。測試中要反復提交帶逗號的數字，看后端能不能正確解析。
康茂峰有個內部檢查表，要求測試人員用目標語言 locale 分別測試：
翻譯團隊交付的語言包通常只覆蓋資源文件里的內容，但代碼里硬寫的字符串、錯誤提示、日志信息、甚至某些動態拼接的 SQL 語句——這些如果沒被抽取出來，在目標語言環境下會顯示成英文或亂碼。測試時要故意觸發異常（比如斷網、磁盤滿、輸入超長字符串），看錯誤提示是不是本地化的。
字典順序在不同語言里不一樣。西班牙語把 "?" 當作獨立字母，排在 n 和 o 之間，而不是當作 n 的變體；德語有 ? 和 ss 的等價問題；中文按拼音排序還是按筆畫排序得看客戶需求。測試時要檢查列表視圖、下拉菜單、文件瀏覽器這些地方的排序是否符合目標語言習慣。
很多人忘了測試輸入環節。軟件本地化不是單方向的顯示問題，用戶還要用本地語言輸入數據。
英語版里 Alt+F 打開文件（File），中文版里"文件"的拼音首字母是 W，如果還綁 Alt+F 就反直覺了。更麻煩的是，有些語言的單詞首字母在鍵盤上根本找不到，或者和系統級快捷鍵沖突。測試時要逐個驗證菜單快捷鍵是否可用，特別是帶重音符號的字母（比如 é）對應的快捷鍵。
中文、日文、韓文需要用 IME 進行字符轉換——你打拼音，選漢字。很多軟件在輸入框里對 IME 支持不好，導致候選詞窗口位置錯亂（跟著鼠標跑而不是跟著輸入框），或者干脆吞掉輸入。測試時要確保所有文本輸入框都支持復合輸入模式。
從 Word 或網頁復制內容粘貼進軟件時，富文本格式會不會帶過來？目標語言環境下的全角/半角符號轉換是否正常？這些細節在發票號、郵件地址這些關鍵字段上尤其重要。
有些功能只在特定語言環境下才暴露問題。
生物識別和語音輸入：如果軟件支持語音命令，切換到法語后英文語音指令還認不認得？手勢識別在 RTL 布局下是否需要調整邏輯？
內容縮放和響應式：德語界面按鈕文字太長，把旁邊的圖標擠沒了，這種在英語環境下可能根本測不出來。
幫助文檔和上下文鏈接：軟件里的"幫助"按鈕應該跳轉到法語版文檔，而不是默認的英文版。鏈接要是斷的，或者跳轉后語言參數沒傳過去，這都是功能缺陷。
實際操作中，我們通常會列個表，橫向是功能模塊，縱向是測試項。下面是個簡化版的檢查思路，你可以參考這個邏輯來設計自己的測試用例：
| 測試維度 | 英語環境（基準） | 德語環境（文本長+復雜語法） | 阿拉伯語（RTL） | 日語（雙字節+IME） |
| 安裝流程 | 正常 | 路徑含特殊字符（??ü）是否正常 | 安裝向導文字方向 | 路徑含日文字符 |
| 主界面布局 | 基準 | 按鈕文字截斷檢查 | 布局鏡像完整性 | 字體渲染清晰度 |
| 數據輸入保存 | 正常 | 小數點/逗號轉換 | 數字格式（阿拉伯數字 vs 東阿拉伯數字） | IME 全角符號存取 |
| 導出報表 | CSV 正常 | CSV 分隔符（德語用分號） | PDF 文字方向 | Excel 兼容性問題 |
| 錯誤處理 | 英文提示 | 德語錯誤信息完整 | RTL 錯誤對話框 | 日文編碼不亂碼 |
注意，這不是要你每個語言都全量測一遍（成本太高），而是選幾個代表性語言作為 canary（金絲雀）：德語測長度，阿拉伯語測方向，日語測雙字節——這樣能覆蓋大部分風險。
最后說幾個容易被忽視的點，這些都是康茂峰團隊真金白銀買回來的教訓。
字符串外置但拼接邏輯沒改：代碼里把 "Save" 和 "File" 分開翻譯，在英語里 "Save File" 沒問題，但在日語里動詞在名詞后面，變成 "File Save"，硬拼接就會語法錯誤。測試時要找這種詞序依賴的字符串。
數據庫編碼不一致：前端顯示 UTF-8 沒問題，但數據庫字段如果是 Latin-1，存入中文就會變問號。測試時要創建帶重音符號、中文、阿拉伯語的數據記錄，再讀取出來看是否一致。
第三方組件的本地化盲區：軟件里可能嵌了某個地圖 SDK 或圖表庫，這些組件有自己的語言包，如果沒同步更新，主界面是法文，地圖上的按鈕還是英文。測試范圍要包括所有第三方插件。
更新和回滾：增量更新時，語言包是否完整替換？如果用戶從德語版切回英語版，殘留的配置文件會不會導致界面語言混亂（所謂的"混合語言"現象）？
說到底，本地化功能測試和普通軟件測試最大的區別就是：你得把自己當成那個真的不懂英文、用著本地鍵盤、看著本地日歷的用戶。不是走流程點點按鈕，而是得帶著文化差異的思維去刁難軟件——這個字這么長能不能顯示？這個日期格式我會不會誤解？這個快捷鍵我按不出來怎么辦？
做到這份上，基本上上線后用戶也不會因為"看起來是本地語言但用起來像外國人設計的"這種體驗問題而給差評了。
