京东多语言质量解决方案
李小磊约 9 分钟本文聚焦京东全球售多语言测试，点明业界三大通用挑战及京东 APP多维度、技术栈复杂的特有难题，还有 QA 面临的场景覆盖等困境。随后打造接口 + 页面 + 用户动线三层测试体系，结合自动化、智能体等策略，实现 UI 层提效超 100 倍、API 层提效 70%+。同时嵌入研发全流程，未来将持续完善全球化测试与安全生产体系，升级本地化体验。
01
业界多语言面临的通用挑战是什么
1.语言物料生产阶段：对于存量未接入多语言平台（70%）的模块，会有潜在代码会未配置Key的问题，而对于已接入模块会出现错配置Key问题，最终导致端上的文案不展示及展示错误问题。
2.标准化流程缺失：在研发阶段，新增多语言文案的流程缺失，大部分模式是业务方、内容团队、开发同学通过翻译平台是弱管控。需要PRD语言类key标准化->翻译平台录入->研发流程流程门禁检测+端上测试->Key发布上线管理。
3.海外测试仿真度低：全球化用户遍布全球各地，质量同学想要真实模拟不同地区的用户的真实体验挑巨大，海外用户手机适配的挑战也将远远大于国内。且语言类特有的漏翻\错翻\文案截断问题在UI层的问题突出，而当前手工程度高，问题发现能力弱。与此同时可以预见，若扩充到其他语言时工作量会成倍增加。如下是全球用户在品牌、机型、系统和分辨率上的差异。
02
面临的挑战却远不止于此
1. 我们京东商城是航母级的APP，产品形态多样
一般有4个维度：地区/国家 & 语言 & 币种 & 时区
地区国家：0-大陆、5-港澳、7-台湾、8-美国、9-日本、10-新加坡、11-马来西亚、12-泰国、13-韩国、14-越南、15-柬埔寨、100-海外
语言：简体中文=zh_CN、美式英语=en_US、繁体中文=zh_HK（仅港澳台湾）
币种：
用户设置币种 | 货币符号 | 展示类型 | 金额表达示例（10元） |
HKD | HK$ | B | HK$10.99 |
TWD | NT$ | B | NT$10.99 |
USD | $ | B | $10.99 |
JPY | JP¥ | B | JP¥10 |
SGD | S$ | B | S$10.99 |
MYR | RM | B | RM10.99 |
THB | ฿ | B | ฿10.99 |
KRW | ₩ | B | ₩10 |
VND | ₫ | B | ₫10 |
KHR | ៛ | B | ៛10.99 |
AUD | AU$ | B | AU$10.99 |
AED | د.إ | A | د.إ10.99 |
EUR | € | B | €10.99 |
GBP | £ | B | £10.99 |
CAD | CA$ | B | CA$10.99 |
NZD | NZD$ | B | NZD$10.99 |
MXN | Mex$ | B | Mex$10.99 |
时区：
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侧进行时区转换。
全链路涉及模块：
03
对QA而言，挑战是巨大的，具体是什么？
3.1 挑战一：覆盖的页面场景多，英文版2.0的围绕20+个业务，涵盖零售&科技&物流&健康全链路。
交易域：商详、结算、购物车、凑单、换购、订单/订详、收银台、支付成功、价保、店铺、售后
导购&流量：首页、拍照购、分类、评价、消息中心、搜索、推荐、我京及核心二三级页、权益中心、plus、等级会员、发票、客服。
3.2 挑战二：页面 & 语言 & 汇率 & 时区的笛卡尔积，将极大的增加测试验证工作量。
除大陆站点外，中文模式下的时区也需要验证。所以有更多的页面进入覆盖场景。如：咚咚客服、活动日历、短信、延保服务、账单。
3.3 挑战三：即使每个页面能否走到，每个页面的测试深度无法穷举。
04
京东全球售-测试方案
4.1 目标
进行自动化问题检测，提升走查效率。提供修复建议，提升全球售本地化体验。
4.2 整体思路
通过接口、页面、用户动线三层验证思路进行验证。并通过汇率接口限流，验证页面兜底情况。
4.3 策略一【接口层】通过梳理全量使用价格计算的接口，进行币种设置，批量测试。
面向中台：JSF接口设置DongContext，验证不同语言下的返回。如：台账 （PayResource.queryOrder - 查询应付金额（收银台））、到手价中台、、价促平台、、预售价中台、。
面向前台：color网关接口设置DongContext，验证不同语言就需要前台端SOA对接科技接口获取汇率，再从外币价格jar包获取外币金额，并前端表达。接口性能要求80ms，如果性能不足需要降级不展示。
期望的结果：
4.4 策略二【页面级测试】一键触发核心场景组合，并自动化结果校验。
1. 核心场景组合定义：
（P0）港澳-繁体-港币-UTC+8
（P0）台湾-英文-台币-UTC+8
（P0）新加坡-英文-新币-UTC+8
（P0）澳大利亚-英文-AUD-UTC+11
（P0）大陆-英文-美元-UTC+8
2. 自动化切换、截图、跳转、文案检测识别。
3. 结果验证，翻译错误、翻译质量。
4.5 策略三：【常态化保鲜】通过APP回归、兜底演练动作防裂化
4.6 策略四：【智能体Agent】探索智能体方案，进行翻译质量检测
基于赛博平台对各页面的识别结果，将接口中翻译后的内容提取出来并输送给智能体，由智能体来检测多语言翻译的准确性。
05
做到什么程度
5.1 工程上的提效价值：
计算公式如下：
| Before | After | |
|---|---|---|
| UI层 | 执行：36个page ✖️ 9（站点+语言+币种） ✖️ 5 mins ✖️ 2端 = 3240mins 检测：648页面人工check * 0.5 mins = 324mins | 执行上：子用例集维度： 1次执行（36个page并行） ✖️ （9个场景并行） ✖️ 30mins（ 双端并行）= 30mins 检测维度：目标90%的check可以通过检测脚本搞定。324 ✖️（1-90%）= 32.4mins。 |
| API层 | 涉及color网关（4.8万接口）和非color网关接口，以及HSF接口 | 单接口调试及多接口回归自动化验证，可以提效约70%以上 |
结果展示1：聚合页对比10种场景
提效10倍。计算公式：10（页面+语言+比重）* 3端的情况下：
结果展示2：自动检测
提效100%。计算公式≈通过的问题数在总问题数中的比例，意味着是自动检测。
具体测试包括见：【15.3.20】- 多语言自动化测试报告。 （涉及到内部网站，请联系作者进行报告链接获取）
5.2 大模型上的实践价值：
5.3 零售研发流程的多语言升级价值
| 场景/功能 | 详细描述 | 原型 | |
| 创建设计 | 创建设计时给出提醒 | ·选择迭代设计，选择需求后，识别需求的多语言字段 ·若打标为是，则给出黄色区域文案提示： ·所选需求涉及多语言，请在设计用例过程中重点关注 ·不涉及联调设计 | |
| 编写用例 | 编写用例时支持批量打标签 | ·目录、用例批量操作增加添加标签操作； ·点击添加标签，弹框展示标签输入的弹框，点击确定后，追加至所选用例的标签字段 | |
| 用例打标 | 单用例详情页，支持用户打标签 | 多语言系统标签用户点击添加默认推荐出来 | |
| 用例评审 | 时给出提示提醒 | 点击评审完成时，判断下需求是否有对应标记，若有标记，则增加一个根据标签统计多语言用例的区域，若用例数为0，则0红色高亮显示，并展示建议补充文案 不涉及联调设计 | |
| 发版回归 | 一键触发自动化巡检 | ·页面 x 语言 x 汇率 x 时区的的测试组合场景，进行高效执行和批量验证。 http://cyber.test.jd.com/#/autotest/i18nAutomation·长期规划：一键报Bug、单模块定时巡检、嵌入APP发版回归平台流程、大模型质量翻译嵌入平台。 | |
06
未来规划
6.1 大而全的质量保障整体方案
1. 【已完成】标准化多语言研发流程。多语言检测能力覆盖整个语言生产过程。
2. 【进行中】建设全球化测试体系化能力。测试资源：构建手机号、银行卡、支付账号、测试账号、云测真机、网络仿真，构建研测阶段的真实海外环境。效率&体验：通过多端的功能的自动化，提升测试回归阶段的多机适配效率。通过多环境的app性能测试（核心页面、图片、视频），例如美国、印度和欧洲的页面秒开率会有很大区别，提前发现端侧性能问题。体验巡检：联合本地化外包、海外产设团队，进行线上用户体验走查，真实模拟用户现场发现体验问题。
3. 【未开始】建设全球化安全生产体系。攻防演练：在多租户并行的部署架构下，进行域名、接口级别的攻防演练，提升系统的海外高可用性。海外压测：压测平台能力进行扩充，涵盖海外用户特征的压测数据及脚本以及多机房混压，提升海外服务稳定性。
策略大图见下：
6.2 翻译质量智能体
语言度量能力：通过GPT Based MQM（Multidimensional Quality Metrics），构建国际化水位分数，助力owner&团队看清缺陷密度水位。