一、業界多語言面臨的通用挑戰是什么

做這個事之前，我們先看看業界做了什么。

??阿里巴巴全球化測試技術介紹?

??螞蟻全球化無線端質量解決方案?

??談談多語言測試?

總結下來，需要面臨3個通用問題：

1.語言物料生產階段：對于存量未接入多語言平臺（70%）的模塊，會有潛在代碼會未配置Key的問題，而對于已接入模塊會出現錯配置Key問題，最終導致端上的文案不展示及展示錯誤問題。

2.標準化流程缺失：在研發階段，新增多語言文案的流程缺失，大部分模式是業務方、內容團隊、開發同學通過翻譯平臺是弱管控。需要PRD語言類key標準化->翻譯平臺錄入->研發流程流程門禁檢測+端上測試->Key發布上線管理。

3.海外測試仿真度低：全球化用戶遍布全球各地，質量同學想要真實模擬不同地區的用戶的真實體驗挑巨大，海外用戶手機適配的挑戰也將遠遠大于國內。且語言類特有的漏翻錯翻文案截斷問題在UI層的問題突出，而當前手工程度高，問題發現能力弱。與此同時可以預見，若擴充到其他語言時工作量會成倍增加。如下是全球用戶在品牌、機型、系統和分辨率上的差異。

?

二、面臨的挑戰卻遠不止于此。因為我們京東商城是航母級的APP，意味著

1. 產品形態多樣

一般有4個維度：地區/國家 & 語言 & 幣種 & 時區

地區國家：0-大陸、5-港澳、7-臺灣、8-美國、9-日本、10-新加坡、11-馬來西亞、12-泰國、13-韓國、14-越南、15-柬埔寨、100-海外

語言：簡體中文=zh_CN、美式英語=en_US、繁體中文=zh_HK（僅港澳臺灣）

幣種：

?

時區：

1.若用戶設置語言是英文，則轉換時區后用英語時間表達格式：日月年 時分秒。如：年月日 時分秒：2025-06-07 23:59:59，轉換成英文：07 Jun 2025 23:59:59(UTC+8)

2.若用戶設置語言是中文&繁體，則轉換時區后時間表達格式：年月日，時分秒。

3.返回目標地區的UTC時區值（T），時區由各模塊自己判斷是否要展示。

2. 技術棧多，技術架構復雜

2.1 語言類-客戶端

- 場景1： 端頁面可從多語言SDK獲取“國家/區域”，“語言”，“模式”參數，處理自定義的業務邏輯；網絡請求使用“京東零售基礎網路庫”加載端頁面。基礎庫負責統一上傳“國家/區域”，“語言”，“模式”參數，端無須特殊處理。

- 場景2：端頁面可從多語言SDK獲取“國家/區域”，“語言”，“模式”參數，處理自定義的業務邏輯；網絡請求不使用“JD零售基礎網路庫”，端需要自己參照參數規則，上傳“國家/區域”，“語言”，“模式”參數。

2.2 語言類-后端

傳遞方式：客戶端->網絡庫/非網絡庫->color網關/非color網關->SOA->后臺服務（JSF隱式傳參）。

使用方式：服務端從全局上下文SDK中讀取，不允許篡改。SOA及后臺服務需要接入dongboot內核+donglog+dongcontext+dongthread

2.3 匯率類-設計

換算原則：SOA調用科技匯率接口獲取匯率，傳給價格源（到手價/原價團隊/預售價）進行外幣價格計算；若展示價格由中臺計算，例如購物車勾選后價格和結算頁支付價格，則由中臺進行外幣價格計算。核心頁面外幣金額展示示例：

2.4 時區類-設計

1. 當端SOA側依賴的上游返回的String類型的文案里面如果包含日期或時間，由中后端上游進行時區轉換。

2. 當端SOA側依賴的上游返回了時間戳/Date格式的日期或時間，由端SOA側進行時區轉換。

全鏈路涉及模塊：

?

三、對QA而言，挑戰是巨大的，具體是什么？

3.1 挑戰一：覆蓋的頁面場景多，英文版2.0的圍繞20+個業務，涵蓋零售&科技&物流&健康全鏈路。

交易域：商詳、結算、購物車、湊單、換購、訂單/訂詳、收銀臺、支付成功、價保、店鋪、售后

導購&流量：首頁、拍照購、分類、評價、消息中心、搜索、推薦、我京及核心二三級頁、權益中心、plus、等級會員、發票、客服。

3.2 挑戰二：頁面 & 語言 & 匯率 & 時區的笛卡爾積，將極大的增加測試驗證工作量。

除大陸站點外，中文模式下的時區也需要驗證。所以有更多的頁面進入覆蓋場景。如：咚咚客服、活動日歷、短信、延保服務、賬單。

3.3 挑戰三：即使每個頁面能否走到，每個頁面的測試深度無法窮舉。

1.流量&導購類頁面千人千面，依賴于賬戶維度的豐富度。如：

2.交易類頁面，依賴較多前置條件：如：

1.商詳：樓層多，需要不同的SKU。

2.結算：樓層多，需要不同的SKU。

3.購物車：依賴賬戶加車狀態、比如預售&定金的時間表達

4.湊單：可能無法通過OpenAPP協議進入。

5.收銀臺：目前不支持OpenAPP協議進去。

6.訂單：依賴賬戶內的訂單、二級彈層不依賴于openAPP協議。

7.promise：“付款時間”保持和當前用戶時區一致、“發貨時間”和“送達時間”保持與收貨地時區一致。

?

四、京東全球售-測試方案

4.1 目標

進行自動化問題檢測，提升走查效率。提供修復建議，提升全球售本地化體驗。

4.2 整體思路

通過接口、頁面、用戶動線三層驗證思路進行驗證。并通過匯率接口限流，驗證頁面兜底情況。

4.3 策略一【接口層】通過梳理全量使用價格計算的接口，進行幣種設置，批量測試。

面向中臺：JSF接口設置DongContext，驗證不同語言下的返回。如：臺賬 （PayResource.queryOrder - 查詢應付金額（收銀臺））、到手價中臺（計算外幣價格-結算網關接口文檔） 、價促平臺（主站新增外幣金額表達-接口文檔）、預售價中臺（4.2 批量獲取當前進行中的預售）。

面向前臺：color網關接口設置DongContext，驗證不同語言就需要前臺端SOA對接科技接口獲取匯率，再從外幣價格jar包獲取外幣金額，并前端表達。接口性能要求80ms，如果性能不足需要降級不展示。

期望的結果：

?外幣金額計算規則：外幣金額=本幣 X 匯率。

?外幣金額小數點處理：VND（越南盾）、KRW（韓元）、JPY（日元）三個幣種，外幣金額四舍五入取整數；其他幣種，外幣金額四舍五入，最多保留2位小數，小數點后0要抹去。

4.3 策略二【頁面級測試】一鍵觸發核心場景組合，并自動化結果校驗。

1. 核心場景組合定義：

（P0）港澳-繁體-港幣-UTC+8

（P0）臺灣-英文-臺幣-UTC+8

（P0）新加坡-英文-新幣-UTC+8

（P0）澳大利亞-英文-AUD-UTC+11

（P0）大陸-英文-美元-UTC+8

2. 自動化切換、截圖、跳轉、文案檢測識別。

3. 結果驗證，翻譯錯誤、翻譯質量。

4.3 策略三：【常態化保鮮】通過APP回歸、兜底演練動作防裂化

1.一鍵觸發：打通測試回歸計劃，多任務手動一鍵出發/定時觸發/接口觸發，輸出報告需要對任務整體通過率計算。內容包括：遍歷的頁面，每個子任務（當成一條用例）除了展示完成的狀態，還需要展示通過率，錯誤的個數，通過的個數等。

2.設備選擇：實現基于系統、機型、分辨率、國內外品牌等維度篩選機型。

3.發版報告：①報告類增加小 i解釋：通過/忽略的標準，例如明確告知除了人名/圖片，其余內容均需進行翻譯，以及相關類別問題的研發接口人。

4.4 策略四：【智能體Agent】探索智能體方案，進行翻譯質量檢測

基于賽博平臺對各頁面的識別結果，將接口中翻譯后的內容提取出來并輸送給智能體，由智能體來檢測多語言翻譯的準確性。

?

五、做到什么程度

5.1 工程上的提效價值：

?執行上：3240mins->30mins

?檢測上：324mins->32.4mins

計算公式如下：

結果展示1：聚合頁對比10種場景

提效10倍。計算公式：10（頁面+語言+比重）* 3端的情況下：

?人工：10*3*5（分鐘）=150min

?自動：15分鐘

結果展示2：自動檢測

提效100%。計算公式≈通過的問題數在總問題數中的比例，意味著是自動檢測。

具體測試包括見：【15.3.20】- 多語言自動化測試報告。 （涉及到內部網站，請聯系作者進行報告鏈接獲取）

?

5.2 大模型上的實踐價值：

翻譯的精準度不夠：item(s)	翻譯截斷	翻譯不準確 scrape 本義 “刮擦”，引申為「技術爬蟲抓取」，隱含 “非正常手段獲取”“批量爬取” 的負面意味，應改為collection	中文未翻譯

?15.2.80多語言翻譯質量檢測，發現13個翻譯類問題。見15.2.80多語言翻譯質量檢測報告?

?智能體經過3輪優化，采納率11%提升至85.71%。

5.3 零售研發流程的多語言升級價值

場景/功能		詳細描述	原型
創建設計	創建設計時給出提醒	·選擇迭代設計，選擇需求后，識別需求的多語言字段 ·若打標為是，則給出黃色區域文案提示： ·所選需求涉及多語言，請在設計用例過程中重點關注 ·不涉及聯調設計
編寫用例	編寫用例時支持批量打標簽	·目錄、用例批量操作增加添加標簽操作； ·點擊添加標簽，彈框展示標簽輸入的彈框，點擊確定后，追加至所選用例的標簽字段 ?·聯調設計同步支持
用例打標	單用例詳情頁，支持用戶打標簽	多語言系統標簽用戶點擊添加默認推薦出來
用例評審	時給出提示提醒	點擊評審完成時，判斷下需求是否有對應標記，若有標記，則增加一個根據標簽統計多語言用例的區域，若用例數為0，則0紅色高亮顯示，并展示建議補充文案 不涉及聯調設計
發版回歸	一鍵觸發自動化巡檢	·頁面 x 語言 x 匯率 x 時區的的測試組合場景，進行高效執行和批量驗證。 http://cyber.test.jd.com/#/autotest/i18nAutomation·長期規劃：一鍵報Bug、單模塊定時巡檢、嵌入APP發版回歸平臺流程、大模型質量翻譯嵌入平臺。	?

?

六、未來規劃

6.1 大而全的質量保障整體方案

1. 【已完成】標準化多語言研發流程。多語言檢測能力覆蓋整個語言生產過程。

2. 【進行中】建設全球化測試體系化能力。測試資源：構建手機號、銀行卡、支付賬號、測試賬號、云測真機、網絡仿真，構建研測階段的真實海外環境。效率&體驗：通過多端的功能的自動化，提升測試回歸階段的多機適配效率。通過多環境的app性能測試（核心頁面、圖片、視頻），例如美國、印度和歐洲的頁面秒開率會有很大區別，提前發現端側性能問題。體驗巡檢：聯合本地化外包、海外產設團隊，進行線上用戶體驗走查，真實模擬用戶現場發現體驗問題。

3. 【未開始】建設全球化安全生產體系。攻防演練：在多租戶并行的部署架構下，進行域名、接口級別的攻防演練，提升系統的海外高可用性。海外壓測：壓測平臺能力進行擴充，涵蓋海外用戶特征的壓測數據及腳本以及多機房混壓，提升海外服務穩定性。

策略大圖見下：

6.2 翻譯質量智能體

語言度量能力：通過GPT Based MQM（Multidimensional Quality Metrics），構建國際化水位分數，助力owner&團隊看清缺陷密度水位。

審核編輯 黃宇