本文聚焦京东全球售多语言测试，点明业界三大通用挑战及京东 APP多维度、技术栈复杂的特有难题，还有 QA 面临的场景覆盖等困境。随后打造接口 + 页面 + 用户动线三层测试体系，结合自动化、智能体等策略，实现 UI 层提效超 100 倍、API 层提效 70%+。同时嵌入研发全流程，未来将持续完善全球化测试与安全生产体系，升级本地化体验。
一、业界多语言面临的通用挑战是什么
1.语言物料生产阶段：对于存量未接入多语言平台（70%）的模块，会有潜在代码会未配置Key的问题，而对于已接入模块会出现错配置Key问题，最终导致端上的文案不展示及展示错误问题。
2.标准化流程缺失：在研发阶段，新增多语言文案的流程缺失，大部分模式是业务方、内容团队、开发同学通过翻译平台是弱管控。需要PRD语言类key标准化->翻译平台录入->研发流程流程门禁检测+端上测试->Key发布上线管理。
3.海外测试仿真度低：全球化用户遍布全球各地，质量同学想要真实模拟不同地区的用户的真实体验挑巨大，海外用户手机适配的挑战也将远远大于国内。且语言类特有的漏翻\错翻\文案截断问题在UI层的问题突出，而当前手工程度高，问题发现能力弱。与此同时可以预见，若扩充到其他语言时工作量会成倍增加。如下是全球用户在品牌、机型、系统和分辨率上的差异。
二、面临的挑战却远不止于此
- 我们京东商城是航母级的APP，产品形态多样 一般有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.1 语言类-客户端 场景1：端页面可从多语言SDK获取“国家/区域”，“语言”，“模式”参数，处理自定义的业务逻辑；网络请求使用“京东零售基础网路库”加载端页面。基础库负责统一上传“国家/区域”，“语言”，“模式”参数，端无须特殊处理。
场景2：端页面可从多语言SDK获取“国家/区域”，“语言”，“模式”参数，处理自定义的业务逻辑；网络请求不使用“JD零售基础网路库”，端需要自己参照参数规则，上传“国家/区域”，“语言”，“模式”参数。
2.2 语言类-后端 传递方式：客户端->网络库/非网络库->color网关/非color网关->SOA->后台服务（JSF隐式传参）。
使用方式：服务端从全局上下文SDK中读取，不允许篡改。SOA及后台服务需要接入dongboot内核+donglog+dongcontext+dongthread
2.3 汇率类-设计 换算原则：SOA调用科技汇率接口获取汇率，传给价格源（到手价/原价团队/预售价）进行外币价格计算；若展示价格由中台计算，例如购物车勾选后价格和结算页支付价格，则由中台进行外币价格计算。核心页面外币金额展示示例：
2.4 时区类-设计
-
当端SOA侧依赖的上游返回的String类型的文案里面如果包含日期或时间，由中后端上游进行时区转换。
-
当端SOA侧依赖的上游返回了时间戳/Date格式的日期或时间，由端SOA侧进行时区转换。
全链路涉及模块：
三、对QA而言，挑战是巨大的，具体是什么？
3.1 挑战一：覆盖的页面场景多，英文版2.0的围绕20+个业务，涵盖零售&科技&物流&健康全链路。 交易域：商详、结算、购物车、凑单、换购、订单/订详、收银台、支付成功、价保、店铺、售后
导购&流量：首页、拍照购、分类、评价、消息中心、搜索、推荐、我京及核心二三级页、权益中心、plus、等级会员、发票、客服。
3.2 挑战二：页面 & 语言 & 汇率 & 时区的笛卡尔积，将极大的增加测试验证工作量。 除大陆站点外，中文模式下的时区也需要验证。所以有更多的页面进入覆盖场景。如：咚咚客服、活动日历、短信、延保服务、账单。
3.3 挑战三：即使每个页面能否走到，每个页面的测试深度无法穷举。 1.流量&导购类页面千人千面，依赖于账户维度的丰富度。如：
2.交易类页面，依赖较多前置条件：如：
商详：楼层多，需要不同的SKU。
结算：楼层多，需要不同的SKU。
购物车：依赖账户加车状态、比如预售&定金的时间表达
凑单：可能无法通过OpenAPP协议进入。
收银台：目前不支持OpenAPP协议进去。
订单：依赖账户内的订单、二级弹层不依赖于openAPP协议。
promise：“付款时间”保持和当前用户时区一致、“发货时间”和“送达时间”保持与收货地时区一致。
四、京东全球售-测试方案
4.1 目标 进行自动化问题检测，提升走查效率。提供修复建议，提升全球售本地化体验。
4.2 整体思路 通过接口、页面、用户动线三层验证思路进行验证。并通过汇率接口限流，验证页面兜底情况。
4.3 策略一【接口层】通过梳理全量使用价格计算的接口，进行币种设置，批量测试。 面向中台：JSF接口设置DongContext，验证不同语言下的返回。如：台账 （PayResource.queryOrder - 查询应付金额（收银台））、到手价中台、、价促平台、、预售价中台、。
面向前台：color网关接口设置DongContext，验证不同语言就需要前台端SOA对接科技接口获取汇率，再从外币价格jar包获取外币金额，并前端表达。接口性能要求80ms，如果性能不足需要降级不展示。
期望的结果：
外币金额计算规则：外币金额=本币 X 汇率。
外币金额小数点处理：VND（越南盾）、KRW（韩元）、JPY（日元）三个币种，外币金额四舍五入取整数；其他币种，外币金额四舍五入，最多保留2位小数，小数点后0要抹去。
4.4 策略二【页面级测试】一键触发核心场景组合，并自动化结果校验。
- 核心场景组合定义：
（P0）港澳-繁体-港币-UTC+8
（P0）台湾-英文-台币-UTC+8
（P0）新加坡-英文-新币-UTC+8
（P0）澳大利亚-英文-AUD-UTC+11
（P0）大陆-英文-美元-UTC+8
-
自动化切换、截图、跳转、文案检测识别。
-
结果验证，翻译错误、翻译质量。
4.5 策略三：【常态化保鲜】通过APP回归、兜底演练动作防裂化 1.一键触发：打通测试回归计划，多任务手动一键出发/定时触发/接口触发，输出报告需要对任务整体通过率计算。内容包括：遍历的页面，每个子任务（当成一条用例）除了展示完成的状态，还需要展示通过率，错误的个数，通过的个数等。
2.设备选择：实现基于系统、机型、分辨率、国内外品牌等维度筛选机型。
3.发版报告：①报告类增加小 i解释：通过/忽略的标准，例如明确告知除了人名/图片，其余内容均需进行翻译，以及相关类别问题的研发接口人。
4.6 策略四：【智能体Agent】探索智能体方案，进行翻译质量检测 基于赛博平台对各页面的识别结果，将接口中翻译后的内容提取出来并输送给智能体，由智能体来检测多语言翻译的准确性。
五、做到什么程度
5.1 工程上的提效价值： •执行上：3240mins->30mins
•检测上：324mins->32.4mins
计算公式如下：
结果展示1：聚合页对比10种场景
提效10倍。计算公式：10（页面+语言+比重）* 3端的情况下：
人工：1035（分钟）=150min
自动：15分钟
结果展示2：自动检测
提效100%。计算公式≈通过的问题数在总问题数中的比例，意味着是自动检测。
具体测试包括见：【15.3.20】- 多语言自动化测试报告。 （涉及到内部网站，请联系作者进行报告链接获取）
5.2 大模型上的实践价值：
15.2.80多语言翻译质量检测，发现13个翻译类问题。
智能体经过3轮优化，采纳率11%提升至85.71%。
六、未来规划
6.1 大而全的质量保障整体方案
-
【已完成】标准化多语言研发流程。多语言检测能力覆盖整个语言生产过程。
-
【进行中】建设全球化测试体系化能力。测试资源：构建手机号、银行卡、支付账号、测试账号、云测真机、网络仿真，构建研测阶段的真实海外环境。效率&体验：通过多端的功能的自动化，提升测试回归阶段的多机适配效率。通过多环境的app性能测试（核心页面、图片、视频），例如美国、印度和欧洲的页面秒开率会有很大区别，提前发现端侧性能问题。体验巡检：联合本地化外包、海外产设团队，进行线上用户体验走查，真实模拟用户现场发现体验问题。
-
【未开始】建设全球化安全生产体系。攻防演练：在多租户并行的部署架构下，进行域名、接口级别的攻防演练，提升系统的海外高可用性。海外压测：压测平台能力进行扩充，涵盖海外用户特征的压测数据及脚本以及多机房混压，提升海外服务稳定性。
策略大图见下：
6.2 翻译质量智能体 语言度量能力：通过GPT Based MQM（Multidimensional Quality Metrics），构建国际化水位分数，助力owner&团队看清缺陷密度水位。
