作者：李小磊
一、业界多语言面临的通用挑战是什么
做这个事之前，我们先看看业界做了什么。
•谈谈多语言测试
总结下来，需要面临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 时区类-设计
-
当端SOA侧依赖的上游返回的String类型的文案里面如果包含日期或时间，由中后端上游进行时区转换。
-
当端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 策略二【页面级测试】一键触发核心场景组合，并自动化结果校验。
- 核心场景组合定义：
（P0）港澳-繁体-港币-UTC+8
（P0）台湾-英文-台币-UTC+8
（P0）新加坡-英文-新币-UTC+8
（P0）澳大利亚-英文-AUD-UTC+11
（P0）大陆-英文-美元-UTC+8
-
自动化切换、截图、跳转、文案检测识别。
-
结果验证，翻译错误、翻译质量。
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端的情况下：
•人工：1035（分钟）=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 时区的的测试组合场景，进行高效执行和批量验证。 cyber.test.jd.com/#/autotest/... |
六、未来规划
6.1 大而全的质量保障整体方案
-
【已完成】标准化多语言研发流程。多语言检测能力覆盖整个语言生产过程。
-
【进行中】建设全球化测试体系化能力。测试资源：构建手机号、银行卡、支付账号、测试账号、云测真机、网络仿真，构建研测阶段的真实海外环境。效率&体验：通过多端的功能的自动化，提升测试回归阶段的多机适配效率。通过多环境的app性能测试（核心页面、图片、视频），例如美国、印度和欧洲的页面秒开率会有很大区别，提前发现端侧性能问题。体验巡检：联合本地化外包、海外产设团队，进行线上用户体验走查，真实模拟用户现场发现体验问题。
-
【未开始】建设全球化安全生产体系。攻防演练：在多租户并行的部署架构下，进行域名、接口级别的攻防演练，提升系统的海外高可用性。海外压测：压测平台能力进行扩充，涵盖海外用户特征的压测数据及脚本以及多机房混压，提升海外服务稳定性。
策略大图见下：
6.2 翻译质量智能体
语言度量能力：通过GPT Based MQM（Multidimensional Quality Metrics），构建国际化水位分数，助力owner&团队看清缺陷密度水位。