书接前文,上回书简单介绍了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最高的方法
至此,思路和步骤已经介绍完毕,接下来的文章我会继续跟大家分享各种工具、技术框架在国际化测试中的使用。