说实话，第一次看到西班牙语版的软件把"Cancel"按钮翻译成"取消ar"的时候，我差点把咖啡喷在键盘上。这种看起来离谱的错误，其实就是跳过了本地化测试流程的后果。在康茂峰干了这么多年，从帮初创公司测App到给 enterprise 软件做全球发布，我算是摸透了这套流程的脾气。今天就用大白话给你唠唠，软件本地化测试到底是咋回事，别被那些动不动就拽术语的文档给唬住了。
很多人觉得，本地化嘛，不就是找个翻译把英文改成中文，或者把中文改成法文，然后看看有没有错别字？要是真这么简单，康茂峰也没必要养一整个测试团队了。说白了，本地化测试（L10N Testing）是在看软件换了语言"衣服"之后，还能不能好好干活。
举个生活中的例子。你想把一家中式快餐店开到意大利，光把菜单上的"宫保鸡丁"翻译成"Pollo Kung Pao"远远不够。你得看看意大利的灶台能不能炒出那个火候，收银机能不能打出欧元符号，服务员叫号的时候意大利人听不听得懂，甚至连店里的灯光是不是太亮都得考虑——因为意大利人喜欢在昏黄灯光下吃饭。软件本地化测试干的就是这个：不仅是文字，是整个"用户体验"在另一个文化环境里能不能活。
所以流程的第一步，永远是把心态从"改字"调整到"改体验"。这个认知不对，后面全是白搭。
我们内部有个 checklist，每次项目启动都要过一遍。不是说每个项目都必须严格按照这个顺序一字排开，有些环节可以并行，但大体上逃不出这七步。少一步，后面就可能要返工，那种痛苦，经历过的人都懂。
拿到项目的第一反应往往是"赶紧测"，但我们在康茂峰吃过太多亏之后，强制要求前三天必须做测试计划与资源准备。这包括搞清楚几个基本问题：目标市场到底是哪个？是墨西哥西班牙语还是西班牙西班牙语？软件需要在哪些操作系统版本上跑？有没有特定的合规要求（比如 GDPR 或者某个国家的数据存储规定）？
然后就是准备"弹药"。术语表（Terminology）是重中之重。我们曾经遇到过把"Log in"在某些界面翻译成"登录"，在另一些界面翻译成"进入系统"的情况，用户看得一脸懵。所以准备期就要锁定术语库，最好有客户确认过的双语术语表。还有伪本地化（Pseudo-localization）的脚本也要准备好——这个后面会细说，简单说就是先看看代码底子能不能扛得住多语言。
这一步在康茂峰被称为"基建验收"。很多客户觉得"我的软件英文版跑得好好的，直接翻译就行"，但往往在这个阶段就会发现噩梦。我们要检查的是国际化（I18N）做得扎不扎实。
具体来说，测试工程师会扫一遍代码里的硬编码字符串。啥意思呢？就是那些写死在代码里、没放进资源文件的英文句子，比如错误提示"Error: File not found"。如果这种字符串没去资源文件里取，翻译的时候就根本找不到它，最后只能看着页面上突兀的英文干瞪眼。还有字符串拼接的问题，比如代码里把"Welcome"和某个用户名用硬编码拼在一起，到了德语这种词序复杂的语言就彻底乱套。
另外要检查字符编码。UTF-8 是不是真用上了？数据库支不支持双字节字符？我们测过一个小众行业的软件，表面看支持中文，结果一输入生僻字就乱码，追到根上发现数据库字段还是 Latin-1 编码。这种问题如果在后期才发现，改动成本是指数级增加的。
伪本地化测试就是这时候用的。我们会用一串扩展的伪字符串（比如把"Hello"变成"Ĥęľľőőő"）替换所有界面文字，看看界面会不会崩、按钮会不会被截断。这就像在正式装修前先用纸板搭个模型，看看空间布局有没有硬伤。
等代码底子确认没问题了，才进入正式的语言处理。但测试团队在这个阶段就要介入，不是等翻译完了再看，而是先审一遍翻译记忆库（TM）和风格指南。
风格指南这玩意儿，很多人觉得是束缚，其实它是救命稻草。比如游戏软件和医疗软件的语言风格天差地别。我们在康茂峰做过一个医疗影像软件的本地化，客户要求所有操作提示必须用祈使句，而且不能出现"请"字（因为医生操作需要直接明了）。要是测试人员不知道这个规矩，后面提 bug 都可能提错方向。
这个阶段还要准备测试环境。目标语言的输入法装好了吗？特定地区的时区和日期格式设置正确了吗？测试用例也要本地化——不是把英文测试用例直译过来，而是要根据目标用户的习惯设计。比如测试搜索功能，英文用"search"，但日文用户可能更习惯用"検索"或者片假名，这些输入习惯都要覆盖到。
现在终于到大家理解的"翻译"环节了，但在康茂峰我们叫它UI 本地化验证。这个阶段要盯着屏幕上的每一个像素。
最常见的问题是字符串扩展（String Expansion）。德文往往比英文长 30%，中文虽然字符数少，但字体大小和行高可能需要调整。我们要检查按钮上的文字有没有被截断，菜单栏会不会因为太长而换行导致布局崩坏。还有双向文本（BiDi）的问题，阿拉伯语和希伯来语是从右往左读的，整个界面布局都要镜像，连进度条的走向都得反着来。
图像里的文字也是个大坑。很多软件会把"保存"、"退出"这类文字直接做在按钮图片上，翻译的时候忘了换图，结果就是英文软件里突兀地出现一个中文"保存"按钮。我们在测试清单里专门有一栏检查所有位图（Bitmap）资源。
另外，快捷键和助记符也得重新考虑。英文里 "&File" 表示 Alt+F，到了法文如果文件变成 "&Fichier"，那快捷键可能就变成了 Alt+F 和 Alt+某个法文字母冲突。这些细节都要一个一个对。
这是整个流程里最耗时的部分。软件界面看着是中文了，字体也对齐，但功能是不是还能用？本地化功能测试（Functional L10N Testing）就是要揪出那些"表面没事，里子坏了"的问题。
首先测区域特定功能（Locale-specific Features）。日期格式对不对？美国是 MM/DD/YYYY，欧洲多数是 DD/MM/YYYY，日本可能是 YY年M月D日。排序规则（Collation）也很要命，瑞典语里 å、ä、ö 排在 z 之后，而不是按照 ASCII 码随便扔在字母表里。拼音排序对中国人来说是基本需求，但如果开发团队没做特定处理，"张三"可能就排到"李四"后面去了，因为张（Z）在 ASCII 里比李（L）靠后。
然后是输入处理。日文输入法有全角和半角，韩文有组合字符，泰文没有空格分词。我们要在这些语言环境下疯狂输入，看软件会不会崩溃或保存出错。康茂峰曾经测过一个表单系统，日文用户输入姓名后点击保存，数据库里存的是乱码，追根溯源发现是编码转换在提交时丢了一个字节。
还有文化和法律适配。比如某些图标在不同文化里的含义——竖起大拇指在某些国家是冒犯。颜色也有讲究，白色在西方代表纯洁，在东亚某些场合代表哀悼。这些虽然不是硬性功能 bug，但会影响产品接受度，我们在测试报告里都会标出来。
到了这个阶段，软件功能已经跑通了，现在要找语言专家来做Linguistic Quality Assurance。在康茂峰，我们要求必须是目标语言的母语者，而且最好是懂技术的母语者。
他们检查什么呢？首先是语境（Context）。翻译人员往往是看着字符串列表翻的，比如就看到单个词"Open"，到底是"打开文件"还是"开启会议"还是"开门"？如果在软件里看到的实际场景不对，就要改。还有一致性，同一个术语在整个软件里必须说法一致，不能这里叫"用户"，那里叫"使用者"，另一处又叫"终端客户"。
语法和拼写是基础，但还有风格（Style）。语气对不对？专业软件太口语化显得不严肃，游戏软件太书面又显得生硬。标点符号也要检查，中文用全角符号，英文用半角，法文引号是不对称的« »，这些都要抠。
这个阶段往往会返工好几轮。我们在康茂峰的流程是 LQA 第一轮发现问题，反馈给本地化工程师修改，然后做 Round 2，直到语言质量达到客户设定的评分标准（通常是错误率低于某个千分比）。
前面的 bug 都修了？别急着 champagne。在康茂峰，我们坚持要做回归测试（Regression Testing）。因为改语言 bug 的时候，工程师可能不小心碰了代码，导致原来的功能坏了。或者修复一个界面的布局问题时，影响了另一个分辨率下的显示。
这个阶段还要做验收测试（UAT, User Acceptance Testing）。如果客户有当地的 beta 用户，最好让他们真刀真枪用一下。我们遇到过理论测试都通过了，但真实用户发现软件里的默认纸张大小还是 Letter（美国标准），而目标市场只用 A4，导致打印出来格式错乱的情况。
最后生成测试报告，里面要有 bug 统计、修复率、遗留问题清单，还有给下个项目的技术债务建议。比如"建议在代码层优化字符串外部化机制，减少硬编码风险"这种话，虽然现在的项目做完了，但能帮客户少走下次的弯路。
说点流程文档里不会写的，但实际操作中要命的经验。
上下文缺失是最大杀手。 很多软件用 gettext 或者类似的格式提取字符串，提取出来就是"File"、"Save"这种孤立的词。翻译人员猜不出这个词是动词还是名词，是菜单项还是按钮。康茂峰在项目启动时，一定会要求客户提供截图或视频作为翻译参考，哪怕多花两天时间，也比后期返工强。
别以为 Unicode 就万事大吉。 支持 UTF-8 只是基础，还要看字体渲染。某些小众语言的字符，系统默认字体可能显示为 tofu（方块），你得确保目标用户的系统里要么有字体，要么软件自带 webfont。
测试数据要真实。 用"Test User 1"、"Test User 2"当测试数据，测不出真实 locale 的问题。我们在康茂峰内部维护了一套各国真实姓名、地址、税号格式的测试数据，比如德国邮政编码是五位数，日本地址格式是从大到小。
| 测试类型 | 主要关注点 | 常见 Bug | 康茂峰建议占比 |
| I18N 检查 | 代码底子、硬编码 | 字符串无法提取、编码错误 | 15% |
| UI 验证 | 布局、字体、图像 | 文字截断、按钮错位 | 25% |
| 功能测试 | 逻辑、输入、格式 | 日期解析错误、排序混乱 | 35% |
| LQA | 语言、文化、风格 | 术语不一致、语气不当 | 25% |
这个比例不是死规定，比如游戏软件可能 LQA 占比更高，工业软件可能功能测试更重。但大体上，功能测试永远是大头，毕竟软件首先要能用，再谈说得好不好听。
虽然你问的是流程，但不得不提一嘴工具，因为流程是靠工具落地的。在康茂峰，我们的工具箱大概分这几层：
缺陷管理肯定跑不掉，用来记录、分配、跟踪 bug。关键是字段要定制，得能标记是 I18N bug、UI bug 还是翻译错误，优先级怎么定（比如截断是不是比错别字更严重，这取决于位置和严重程度）。
截图比对工具对我们很重要，特别是多语言版本并列对比，一眼就能看出哪个语言的按钮突出了。
自动化测试脚本能做些基础检查，比如扫描资源文件里有没有硬编码的 ASCII 字符串，或者检查所有对话框的最小尺寸够不够容纳最长的译文。但本地化测试本质上还是深度依赖人工的，特别是文化适配和语言润色这部分，机器替代不了人。
还有虚拟机环境，我们维护着一套各语言版本的纯净操作系统镜像，确保测试环境干净，不会因为测试人员自己电脑装了什么奇怪软件而干扰结果。
说实话，流程这玩意儿，写出来看着都顺，做起来全是对细节的较劲。康茂峰这些年最深刻的体会是：本地化测试不是在项目末尾加一道工序，而是要从软件设计的第一天就介入。 等到代码写完了再来"适配"多语言，那成本是十倍百倍的往上翻。
前两天我刚收尾一个项目，看着那个原本只有英文的手术导航软件，现在流畅地跑在日语、德语和葡萄牙语环境下，医生能用自己的母语操作复杂的 3D 影像，那种成就感，比单纯找几个错别字强烈多了。这大概就是本地化测试真正的价值——让技术真的无国界，或者至少，少点语言构建的墙。
