Web端 - 多语言的测试经验分享

概述

 多语言系统顾名思义就是一个系统同时支持多种语言，可供各国用户正常使用的系统。

比如说哪天B站要去征服国际市场，提供给全球用户下载，那么就得需要支持中文、英语、日语、德语等不同国家的语言，这就是所谓支持多种语言。

但是现实中的多语言可能要更细致一点，不仅是文本显示需要支持多语言，而且还需要软件各个功能都可以在其他语言环境下正常使用，并且还需要符合不同国家的使用习惯，让全球用户都觉得觉得Bilibili不愧是有矿的产业, 好用的一比。哔哩哔哩 (゜-゜)つロ 干杯~

由于近期项目接触到比较多的多语言测试，于是将自己的经验梳理了一下，以供大家参考，不足之处恳请指正。

测试思路

• 怎么进行多语言测试
• 多语言主要对哪几个方面进行测试
• 多语言测试中有哪些容易出错的地方
• 怎么提高多语言测试效率

多语言怎么测

1. 如果你非常熟悉你测的那种语言，将系统语言设置好之后，直接找到相应的功能，进行测试即可。
2. 如果不熟悉或者看不懂要测的语言，由于我们测的是Web端，所以往往会开两个浏览器(chrome和firefox), 一个设置为要测的语言，一个设置为常用语言，两组对照着测，会比较容易定位到功能。

多语言主要对哪几个方面进行测试

     我目前接触的主要是 UI/ 翻译/功能 这三个部分进行测试。

1. UI: 要保证界面上的文本都翻译成相应的语言，UI整体的布局和效果图保持一致（这里的槽点在于我要确定页面的文本都翻译成了我不认识的字）
2. 翻译： 翻译据说是交给专业的团队在做，做完之后会出一张翻译的对照表，对着检查就行。有两个地方需要注意的是：首先，翻译一定要符合当地用户的使用习惯，最好是找本土的团队做。其次，不同语言翻译出来的字符长度是不一致，这种不一致非常容易导致UI出问题。
3. 功能：在多语言切换时，需要保证在不同语言下，系统的功能都可以正常使用

多语言测试中有哪些容易出错的地方

     1.不同国家的语言代号有区别。

         每个国家使用的语言代号有差别。比如香港和我们内地，都是用中文，但是有中文简体Chinese(Simplified)和中文繁体Chinese(Hong Kong)的差别。英语里也有 English (United States)和English (United Kingdom)的区别，具体看系统怎么要求的。

     2.不同国家时区和日期显示习惯不一致。

         比如美国是PST的时区，中国用的是北京时区。时区有差值，所以应该保证同一时间的不同时区显示的数据都应该是正常的。并且每个国家显示时间的习惯也不同，比如中国以24小时制为主，美国则以12小时制度为主。（我踩过有个坑是同为英语，美国时间显示习惯是12小时制，但是英国时间显示习惯是24小时制）还有一个测试过程中需要慎重考虑的点是，本地时间和系统设置的时间之间的关联，这里以后我会在时间测试的bolg里仔细分析。

     3.不同国家货币显示习惯不一样。

         比如通用货币显示格式 1,000.00表示的1000块 ‘,’表示的千分位‘.’表示的是小数位，但是在欧洲某国‘.’表示的千分位‘,’表示的小数位（实在想不清哪个国家了，只记得遇到过记忆尤深）然后还有的国家以空格为主比如 100 000，可见不同国家货币显示的习惯不一致。

     4.过滤条件的显示问题。

         这里需要考虑一下过滤的逻辑，我们遇到过 过滤条件翻译成预期文本，但是用这个预期文本无法过滤的问题，还是按照未翻译之前的文本条件进行过滤。

怎么提高多语言测试效率（待更新）

我认为主要从两个大的方向着手，首先可以通过自动化来缩减测试时间，其次可以通过优化测试数据辅以测试策略来提升效率

1. UI自动化
（这里是计划通，毕竟我也没有机会接触到多语言自动化的机会）
如果在原有语言的基础上系统已经实现了自动化，那么再做多语言的自动化是比较快速并且时间成本的开销也是相对比较小的，因为在多语言的时候页面上元素定位是没有发生改变的，改动的是从后端接口传到前端的数据(我不太确定这个翻译是在接口之前拿到了还是接口之后再处理的,但是我觉得影响应该都不大)，那么做UI自动化的时候只需要把断言依据的数据做出相应的改动

但是这种方法也存在缺陷。缺陷是总不能一种语言对应一套自动化框架吧，我觉得最好的改动就是在原有自动化框架的基础上去新增多语言的断言，而不是单独拿出来做成一套多语言的框架。
还有一个我很顾虑的地方，如果后续再增加新的语言，那是不是每次新增的时候，自动化的框架就要大改? 如果是的话那这种可预见的开销也很大。

所以我觉得比较合适的方法：转换常规语言和多语言的思路，把常规的语言看成多语言中的一种，在多语言里把常规语言的权重排在第一，其他语言根据客户的使用情况来排权重。
旧有的功能已经自动化的后续慢慢改进，融合成适应多语言的框架。
新功能稳定后自动化，不再以主要语言为目的做自动化，而以多语言做自动化目的，以主语言为基准进行融合，支持主要语言的自动化。

最后揣测一下，这个项目甲方的意图，一开始我们这个项目是日语项目，中期才改成多语言的，其实我感觉他们也是把日语当做一个进程来做的。既然日语能做进程，那主语言英语也能做进程中的一种，所以我才有如此感想。

2.优化测试数据辅以测试策略
单语言的测试数据一般是指针对一种语言，但是既然系统支持多语言的话，语言里对应的字符看做符号，那按照理论来说系统应该是支持所有符号的。
基于这个理论，其实每次保证测试数据里涵盖了多种语言，在一种语言中测试，测试后发现这些数据不会对功能产生影响的话，那就能证明功能是支持这些特殊字符的，既然功能都支持了这些字符，那么就算切换成其他语言，也不会出现数据导致的功能问题。所以手动测试我认为没有必要每种语言都单独测一次功能，单测会造成大量冗余。
所以我觉得测试策略可以由都检查调整为：
主语言全测，其他权重较次的语言只需要走主流程，但是所有语言的UI和界面跳转需要检查一遍，过滤这种比较敏感的功能需要全部覆盖。

 参考Blog: https://www.cnblogs.com/mymelon/p/9025287.html