本地化测试的执行分析(总结篇)

上一篇 / 下一篇  2017-06-05 11:42:20 / 个人分类:本地化软件测试

  本地化测试的bug大抵可以分为几类呢?笔者总结如下。
1.因为翻译文件check-in导致原有的功能失效
2.软件本地化之后UIlayout异常或截断
3.硬编码
4.翻译内容不正确
  溯游从之,先说功能点异常或缺失,这可是我们测试的重中之重。我曾多次设想过利用伪翻译之后的build提前引入测试,从而无须等到真实本地化版本的生成就可以完成对其主要功能的验证。但又怎奈翻译人员花样层出不穷,有的甚至将bash中的$符直接翻译成了(美元),导致软件crash…心有余悸啊,所以面对第一点,我目前的态度是保留相关测试用例,但务必代之以与UI无关的自动化测试script,如此方能保证无论软件最终决定要发布几个本地化版本,对测试人员来说都只用开发并维护  一套自动脚本,“凭尔几路来,我只一路去”!只有坚持如此打法,方可百战不殆。
继续看UIlayout,传统模式下,开发人员如何对UI进行设计才能满足软件本地化之后产生的大量遗留layout问题呢?没错,大抵是按照统计学的方式提出如下的一个指导表格,以源语言英文作为参考基准,从而进行预留,但基本也都是经验之谈,保票是万万打不得地。
 英文字符数 本地化后的字符数
 1-6 15字符
 7-25 2.2倍英文字符     长度
 26-40 1.9倍英文字符长度 
41-70 1.7倍英文字符长度
 >70 1.5倍英文字符长度
  面对这样的问题,笔者在上文就提到了团队内部目前在使用的测试工具sniffer,其解决的主要问题就是利用MT提供的真实翻译(也许它并不完美,但却是有着真实语意的文字和长度)对前端页面的交互信息进行替换,从而完成对UIlayout可能出现问题的预判。而不是按照传统统计学的方式,对英文字符数分类,随即再对本地化后的字符数进行预估。
  经过MT转换的前端示意图如上所示,红色标注部分即为layout高危区域。而经过多次实践证明,MT预判出错的可能性几乎不存在(至少到该文章发出时仍未发现)。
Okay!Layout问题既然已经被摆平,继续看硬编码。面对这种小菜,业界早有对策,pseudobuild的制作和产生就使用完美的解决了该问题,使用伪本地化技术,不光是硬编码,所有本地化能力测试都可以一勺烩了。关于Pseudobuild制作,笔者的建议就一点,能自动的千万别手动,能动手的就别光吵吵。
  最后是翻译的准确性问题,假设你精通多国语言,那再好不过。但请切记,这仅仅是对语言内容本身的考核,跟测试还是扯不上一毛钱关系。然而现状是,大部分的测试人员自带的属性仍然是纯天然无添加技术流,自然语言并未大家所长,与其这样浪费时间的去看一堆不知所云的鸟语,还不如将其彻底舍弃,集中优势兵力做好i18n测试,这种语言相关的review就留给语言专家或nativespeaker吧,让正确的人做正确的事儿,岂不美哉?
  四种问题均已遍历,总结发现除了功能验证点必须等到软件真实本地化版本发布后(脚本开发已完成)再行驱动,其余所有问题都已经在更早的时间段内完成了,不因翻译的介入而延迟发布,同时并不会因为本地化测试就引入思维定式的人海战术,这才是本地化测试的正确打开方式,不是么?

TAG: 本地化测试

 

评分:0

我来说两句

Open Toolbar