京东多语言质量解决方案-电子发烧友网

一、业界多语言面临的通用挑战是什么

做这个事之前，我们先看看业界做了什么。

•阿里巴巴全球化测试技术介绍

•蚂蚁全球化无线端质量解决方案

•谈谈多语言测试

总结下来，需要面临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（仅港澳台湾）

币种：

用户设置币种	货币符号	展示类型	金额表达示例（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侧进行时区转换。

全链路涉及模块：

三、对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

计算公式如下：

	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端的情况下：

•人工：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. 【未开始】建设全球化安全生产体系。攻防演练：在多租户并行的部署架构下，进行域名、接口级别的攻防演练，提升系统的海外高可用性。海外压测：压测平台能力进行扩充，涵盖海外用户特征的压测数据及脚本以及多机房混压，提升海外服务稳定性。

策略大图见下：