2016 Unicode Conference拾遗（二）

书接前文，上回书简单介绍了Kat先生和我所共同追求的国际化测试思想，即“战法打法”。本文来谈谈需要完成一个典型国际化release具体的操作步骤，或者说流程吧。一共10条开发标准可作为参考。

1.      抽取所有会在UI上显示的message

●   使用messagelint预防代码错误（Android）

●   使用Pseudolocale(en-XA):查找包含无重音符的消息

●   使用翻译coverage工具

 

2.      将所有抽取的UI message都送交提供语言服务的团队进行翻译

●   使用Translation coverage 工具后，同英文messageset进行比较，上报并分析遗漏掉的翻译

●   对重点语言进行抽样检查（3-5个语言）

 

3.      确保没有严重的UI layout问题

●   Pseudolocales(en-XA/LTR, ar-XB/RTL)

●   Android测试环境下，可使用i18n lint

●   对重点员进行抽样测试

 

另外，Kat先生还提到了自己的best practice，即自动化拍图，提供英文原始图片和本地化后的产品图片，送交linguisticteam review。关于这点，我个人是非常反对的。笔者在过去的几年也做过不少类似的事情，但结果基本都是事倍功半……我对此还进行过大量分析，根据历史数据显示，每拍摄100张图只能产生2个语言相关bug，同时基本都是minorissue。所以，个人的意见是能不拍图就不拍图，能少拍就少拍，直接让LQA登陆产品进行基本的验收测试才是王道。

 

4.      在从右向左的语言环境下，确保所有UI element都已正确的进行了镜像

推荐的方法跟UI layout完全一致，同时Kat先生提到了自己一直在使用的Bidi usability 手册，非常值得大家参考。https://goo.gl/GmfsTr

 

5.      确保用户可以真实的在UI上看到自己选择的本地化文字

●   Kat先生推荐的方法是挑选一个典型场景（例如登陆），对其编写自动化脚本，用来确保软件已经进行了本地化。

不过就我的经验看，此类涉及本地化的场景还是依靠手动测试的抽样检查效率往往更高，也更靠谱。因为笔者亲身经历过不少登陆页面+产品首页均已经被翻译，但newfeature部分却依然是英文的情形。这种情况下，自动化脚本就真的鞭长莫及啦。

 

6.      确保所有功能都能在支持的语言环境下正常工作

●   覆盖multi-locale的功能测试自动化脚本

●   对重要的语言进行手动抽样

在笔者看，只要自动化脚本足够强壮+可信，其实抽样这部也完全可以省略了。

 

7.      Locale相关的format问题在所有locale下都能正确显示

●   添加I18nsanity check unit tests

其实严格的说，我们i18n测试还无法称之为UT，只能称之为白盒测试，不过本文姑且就这么混搭吧。该部分Kat先生提供了开源的测试框架，未来的文章中我会对其进行详解。框架目前可以对一下内容进行测试——date/time, sorted lists, timezone names, number formats, phone numbers等

●   对于format问题，要尽可能避免手动测试，否则将得不偿失

 

8.      输入输出区域能否处理Unicode字符

●   在所有输入输出区域都是用Unicode字符（例如）进行测试

 

其实当下已有不少国际化测试团队使用了类似的super string进行测试，但Kat先生提供的这种明确覆盖UTF-8 1-4 byte的字符组更加值得我们学习和参考。

 

9.      输入输出区域能兼容各种语言键盘

●   在所有输入区域使用mockIMEs进行键盘测试（例如Android,Chrome, iOS等）

 

10.  特定语言环境下的特殊功能良好运行

●   对于只有特定国家，语言环境才能发放的广告，还有不同国家地区对于最小年轻的不同限制的用例。则需要考虑是否需要反复进行回归测试，如是，则尽可能的脚本化；如否，手动测试一定是ROI最高的方法

 

至此，思路和步骤已经介绍完毕，接下来的文章我会继续跟大家分享各种工具、技术框架在国际化测试中的使用。