本地化测试：漏译、回退与截图回归

本地化测试的目标不是证明翻得好，是证明没有哪一处还在说另一种语言。

一、上线前一天，德语界面里冒出中文

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

郑野的库存工具支持中、英、德、法、日五种语言。德语版上线前一天，他随手点了几个页面，在「批量导入」的错误提示里看到一句中文：

文件格式不支持，请检查表头。

他回去查代码，发现这条提示是三个月前新加的，加在了后端返回的错误里，没有进语言包。再查一遍，类似的漏译有 37 条，集中在错误提示、邮件模板与空状态。

更麻烦的是另一类问题：切换语言后，已经打开的页面不刷新，表单里残留着上一种语言的提示。用户以为切换失败，又点了一次，结果提交了两次。

这两类问题都不会让构建失败，也不会让测试报错，只会在用户那里变成一条差评。

二、三类缺陷，三种检测手段

本地化的缺陷可以分成三类，每一类对应一种检测手段。

漏译检测最直接的办法是对齐 key：源语言文件的每个 key，目标语言文件是否都有。缺失的列出来，按模块排序。注意两类例外：有意不翻的（品牌名、代码）要显式标记，而不是靠「反正也没人看」。

回退测试要构造「故意缺一条」的情况，看运行时的行为：是显示源语言、显示 key、还是显示空白。三种行为里，只有第一种可以接受。回退时还应该记录一条事件，方便统计哪种语言缺得多。

伪本地化是把源文案自动替换成「带重音字符 + 加长 + 加括号」的假语言：

源文：Save changes
伪本地化：[Şàvè çhàngèš···]

它同时暴露两类问题：哪些字符串没有被外置（仍然是英文），以及布局在膨胀后是否还撑得住。

三、测试矩阵要剪枝

六种语言 × 十二个关键页 × 三个平台 = 216 种组合。每次发布全测，一个人做不到，也没必要。

剪枝的原则是：语言取全量，页面取关键路径，平台取两个。

剪枝后是 6 × 5 × 2 = 60 种组合。每次发布按 3 分钟一组算，约 3 小时。这个数字仍然不低，所以要把「每次发布全测」改成「每次发布跑自动化，每季度人工全测一次」。

自动化能覆盖的是漏译与回退，加上截图对比；人工要走查的是语气、文化适配与方向性图标。

四、截图回归与小团队的做法

截图回归的原理很简单：给每个「语言 × 页面 × 视口」存一张基线图，改动后重新截，逐像素比较，超过阈值就报警。

基线图数量 = 语言数 × 关键页数 × 视口数
按 6 × 5 × 2 算 = 60 张
每张首次人工确认约 2 分钟 = 2 小时
之后每次发布只处理差异，通常 10–20 分钟

第一周的成本是 2 小时，之后每次发布 10–20 分钟。对一个人的产品，这个投入是划算的，因为它能在发布前拦住「德文按钮被截断」这类问题。

截图回归有两个坑：

• 动态内容：时间、随机数、用户名会让每次截图都不同。截图前要固定时间、用固定的测试账号。
• 字体渲染差异：同一份代码在不同系统上渲染不同。基线图必须与运行环境绑定，最好在容器里跑。

如果不想搭自动化，退而求其次：写一张 20 项的人工清单，每次发布照着点。清单里至少包括：

1. 每种语言的首页标题是否正确。
2. 切换语言后刷新，界面是否全量变化。
3. 切回原语言后，选择是否被记住。
4. 表单校验错误是否是当前语言。
5. 邮件模板（验证、收据、失败提醒）是否本地化。
6. 结账页的货币与语言是否一致。
7. 日期与数字格式是否符合当前语言。
8. 复数形式是否正确（1 个、2 个、5 个各看一次）。
9. RTL 页面的图标方向是否正确。
10. 最长语言下按钮是否截断。
11. 空状态与示例数据是否本地化。
12. 搜索无结果页是否本地化。
13. 通知与推送文案是否本地化。
14. 帮助文档入口是否有该语言版本。
15. 退款政策链接是否指向对应语言。
16. 收据上的地址与税号格式是否正确。
17. 时区显示是否与用户设置一致。
18. 回退语言时是否显示源语言而非空白。
19. 长文本页面是否出现横向滚动。
20. 截图与图片里的文字是否已替换。

清单的价值不在全面，在于每次都一样。每次随缘点几个页面，等于没测。

执行时给每一项标三种状态：通过、失败、不适用。失败项要记下语言与页面，修复后只复测这一项；不适用项要写原因，避免下次又被当成漏测。

测试频率可以按语言数调整：

连续三个版本全部通过，才可以考虑降频；任一版本出现 Critical，恢复全量。

五、行动清单与复算验收

• 对齐源语言与目标语言的 key，列出缺失项并分类处理
• 故意删掉一条翻译，确认回退行为是「显示源语言」而不是空白
• 用伪本地化跑一遍关键页面，记录布局问题
• 按剪枝后的矩阵建测试清单，写明语言、页面与平台
• 为五个关键页建立截图基线，固定时间与测试数据
• 把漏译检查与回退测试接进发布流程，失败则阻塞发布
• 每次发布记录发现的问题数与修复时间

验收标准：能说出当前版本的漏译条数、回退行为、截图基线数量与本次发现的问题数。 只点了首页确认「看起来正常」的，不算测过。

使用边界与实操验收

本文讲本地化的测试与回归，不涉及文案外置的写法，那属于第 03 篇；膨胀与字体的排版规则属于第 05 篇；上线后的分语言复盘属于第 10 篇。

站内另有一篇更偏通用工程的国际化与本地化测试：文案抽取、复数与性别规则、RTL 布局、时区与伪本地化 ，讲的是四层测试与 CI 接入；本文只回答「一个人的产品，每次发布到底测什么、测多少」。

本文也不主张「所有页面都要截图回归」。对只有两种语言的产品，人工清单可能比自动化更划算；随着语言数增加，自动化的边际价值才显现。

验证以发布记录为准：每个版本留存一份「漏译数、截图差异数、人工走查问题数」。三个数字连续两个版本为零，才可以考虑降低测试频率；任一版本出现 Critical（比如结账页语言错乱），恢复全量检查。

关键参考与核验范围

本文的语言数、组合数与工时为教学演示。核验日期：2026-10-23。

• Unicode CLDR ：伪本地化与语言回退的规则基础，尤其是语言标记的匹配与降级顺序。
• Playwright: Visual comparisons ：截图回归的实现方式与基线管理，可作为自建方案的参考。

上述两条只用于说明测试方法的技术背景，不构成对任何工具链的推荐。各测试框架的能力与限制在本次核验中未逐条比对，故不引用其条款原文、不附具体链接。

系列导航

• 上一篇：排版与字体：长度膨胀、断词与复杂文字
• 下一篇：时区、日期与数字：存 UTC，显示本地
• 回到目录：一个人把产品做出海：多语言、时区与本地化
• 相关阅读：排版与字体：长度膨胀、断词与复杂文字 、出海复盘：分语言看转化、留存与支持成本