51Testing软件测试论坛

标题: 游戏公司gameloft的国际化测试介绍 [打印本页]

作者: 阿里路亚 时间: 2010-7-8 14:58
标题: 游戏公司gameloft的国际化测试介绍
Gameloft文本BUG指导手册
前言:
什么是Bug？Bug 的定义很广泛，在软件使用过程中所出现的任何一个可疑问题，或者导致软件不能符合设计要求或满足消费者需要的问题都是Bug，即使这个Bug 在实践中是可行的。有时候，Bug 并不是程序错误。例如，程序没有按照一般用户的使用习惯来运行，此时也可以把这个问题看成是该软件的一个Bug。
那么，我想许多的测试人员也许都对我们现在所说的“文本bug”表示疑惑，到底什么才算是文本Bug？在这里，我想借用一下Bug的广泛定义来做个解释。所谓的文本Bug，指的是任何导致软件的文本显示不正常或者不符合用户语言逻辑、习惯的bug。
本指导手册，主要介绍三个方面的内容。首先，我们要明白哪些是属于多语言文本Bug的范畴，如何去识别它们，从而可以更好的从我们的测试角度来保证多语言版本的游戏品质。其实，通过对文本Bug和游戏类型的关系，我们在测试之前可以预先知道在进入到多语言测试阶段，什么样的项目好做，什么样的项目不好做，预警的同时又对具体的项目类型给各位一个工作指导思想。最后，通过对文本Bug优先等级介绍，让大家从项目全局观的角度认识到文本Bug的处理决策过程，以便提高各位在多语言测试阶段的工作效率。

一、认识文本Bug
1.1 分类:
常见的文本bug主要分为以下几种类别
1. 美术字体，图片错误
包含了所有游戏中艺术字体显示不正确，设计不美观，图片和文本不匹配的错误。
2. 程序设计问题
本来应该在场景A显示的文本却在场景B出现了。
3. 语法规则，风俗文化问题
游戏中的文本不符合某国家的语法规则或者游戏中的对话、旁白等文本不符合该国的风俗文化。
4. 语言逻辑问题
逻辑上存在严重的问题，使得玩家无法理解要表达的意思。
5. 常规的文本bug
这里包括了文本出屏，覆盖等常规的、易于辨认的文本bug。
1.2详细介绍
下面我们来详细的了解每种类型的文本BUG。
1.2.1美术字体，图片错误
这里我们可以继续细化一下分类，将这种类型的Bug继续划分为以下2种情况
1.2.1.1 艺术字设计不合理
我们目前接触到的游戏中都存在大量使用美术字体的情况。如果美术字体的设计出现失误的话会影响整个游戏界面的美观，严重的会造成玩家对游戏文本的阅读障碍。下面我们引用几个典型的艺术字体Bug来详细的认识一下这个问题。
[attach]63612[/attach]
图①:“SOUND & MUSIK”中的“&”符号明显要比其他的字符小很多，这样就影响到整体的文字效果。美术会通过调整“&”符号来修正这个Bug.
图②:图中所显示的字符串“Schnell”中，大写字母“S”和其他的小写字母相比并没有明显的区分，容易使玩家误认为是小写的“S”。所以需要美术重新设计“S”的大写艺术字体。
图③:字母“Q”设计的不太美观，而且使得字符的间的距离变的非常不均匀。
图④: 这张BUG截图是来自Pocket Chef西班牙语版本，我们可以看到“GOOD!”这个艺术字没有使用翻译好的文本，依然显示的是英文，这就是不符合设计要求的艺术字BUG。
图⑤: 通过图中的绿线可以判断出来这一行字符串没有处于同以水平线上，需要调整来避免影响文本的美观效果。
1.2.1.2 图片与对应的文本不符合
导致这种图片和说明文本不匹配的情况主要有两种原因，一是美术人员设计了错误的图片，另一种可能性是开发人员设计的文本调用代码出现了偏差。
图6所示，这个Bug参考了New York Night 2的德语版本。图中穿白衣服的游戏主角站在咖啡机的旁边(图中右方红圈)，但是说明文本框(下方红圈)显示却是”CUISNIERE(炉子)”。显然这个说明文本的调用出现了问题。下面我们再来看另一个项目Pock Chef。
图7正中的绿色物体在游戏中设计应为”香草”....但是玩家根据这幅图片根本无法确认这团绿色物体到底为何物。这就需要对香草的图片进行重新的设计或者增加一条文本对图片进行一个必要的指示说明。
   [attach]63613[/attach]
      （图6）
   [attach]63614[/attach]
      （图7）
测试这种类型的文本Bug需要测试者具有非常强的外语能力。如果是多语言测试的话，对于我们北京的测试人员来说，发现一个德语或者西班牙语的“文不对题”Bug是非常非常困难的一件事情。但是，可以确定的，如果多语言里有此类问题的出现，那就意味着英语里一定也会出现此问题。因此，只要结合英语的GamePlay测试，留意每条英语文本出现的逻辑性，即可很好的解决此类文本Bug。
1.2.2程序设计问题
由于程序设计而导致的文本问题往往不容易被发现。举例来说，当一位刚刚接触到多语言的测试者看到图8中的现象时可能并不会认为有什么不正常的地方。但是这条文本是某个项目的德语版本，图中红色圆圈标示出来的字符正确显示应为 ”ö”。如果是不熟悉多国语言字符的测试人员基本上是无法发现这条文本Bug的。所以，在excel多语言文本里出现的所有特殊字符，我们应该务必按照文本，在版本里逐个字母进行对照审核一次。

[attach]63615[/attach]

      （图8）
当然，也有一些bug是比较容易被发现的，比如图9中的这个。特殊特殊字符没有正确的显示出来，被”?”取代了。

[attach]63616[/attach]
      （图9）
         另一种由于程序设计而导致的文本bug更为严重。文本在游戏中的调用出现了混淆，本应出现在场景A的文本却被错误的调用到场景B中。
1.2.3语法规则，风俗文化问题
这种类型的bug主要出现在多语言版本中。各国语言都有不同的语法规则，对于不熟悉多语言的开发人员来说，出现这样那样的问题都是正常的。而作为一名合格的测试人员，我们的任务就是在能力范围之内，尽自己最大努力找出这类型的bug。如图10所示的问题就是由于开发人员不了解其他语言语法规则的典型错误。对于法语来说，只有小写字母才存在特殊字符，所有的大写字母和英语一样，只是由A-Z的26个字母组成，因此下图中的大写字母标题就是一个bug，应为REINITIALISER。关于所有的字符语法规则，请参考文本组多语言字符表(如果此表有更新，会在第一时间发送给各位)。

[attach]63617[/attach]

         图 10
每个国家都有自己特殊的风俗文化，特别是每个国家都有禁忌的语言、事物。因此要尽量的避免程序中出现不符合当地文化的文本。同样，这项工作主要是通过加拿大的多语言的翻译同事在K800主版本来完成，他们会通过一份用excel编写的bugreport反馈给开发组，我们可以通过这份report来判断中小版本的文本是否符合相关国家的风俗文化。
1.2.4语言逻辑问题
开发人员对游戏文本的设计存在逻辑错误或者不符合普通玩家的语言习惯的bug。
举例来说，一个游戏设计了双人模式，游戏人物在版本里被表示成为player 1’s character和player 2’s character，但是对于大多数的游戏玩家来说他们习惯P1和P2的表示方式。这就是一个不符合玩家语言习惯的文本bug。
1.2.5常规文本Bug
所谓的常规文本bug，实际上就是我们平时经常碰到的文本出屏，覆盖问题。通常解决的办法是通过国外的翻译同事对出现问题的文本经行重新翻译，按照字符需求缩短到一个更为合适的长度。
1.2.6小结
         在这里我们无法罗列出所有的文本bug。对于本地的测试人员来说，我们需要把注意力更多的放在多语言字符设计，程序设计问题和常规的文本bug上。对于其他的文本bug，我们需要文本组保证这些类型的bug被国外翻译人员提交给开发者时，不会被错误的忽略掉，并且能够得到正确的修正。

作者: 阿里路亚 时间: 2010-7-8 14:59
二、游戏类型与文本BUG的联系
考虑到目前文本问题分类趋于细化，影响一个项目文本质量的因素逐步的增多，因此这就需要我们对目前不同类型的项目做一个初步的文本Bug等级分析。这里的等级并非是常规意义上Bug的严重程度，而是对一个项目出现文本问题的一个预先的评估和预警，等级越高的项目意味着越容易出现文本Bug，同时Bug的严重程度也要比其他低等级的项目要高。我们这里主要将所有项目的预警分为S，A，B，C，D这几个类型。主要考虑的因素为：
1．语言文化：不同的国家有不同的语言表达方式，不同的风俗习惯，尊重他人的风俗和语言表示习惯是非常重要的。
2．文本数量：文本越多，出现错误的几率越大。大量的文本非常容易造成例如程序调用出错这样的问题。
3．艺术字效果：当一个项目大量的应用了艺术字体这就意味着有可能会出现大量特殊字符显示不正确，或者是艺术字摆放的位置不合理这样的问题。
4．文本的显示方式：游戏中的文本以何种方式显示。常用的几种方式为普通的根据文本来自动调整的文本框、不可变的文本框和滚动显示的文本框。
按照现有的游戏类型，结合Gameloft以往制作的游戏，我们这里重点分析下列的几个游戏类型：RPG(角色扮演)，ACT(动作游戏)， PZL(益智类)，RCG(竞速类)，SPT(体育类)，SLG(策略类)
D级:
ACT(动作游戏)
分析:
动作类目前我们接触到的代表作是波斯王子和Beowolf。动作类的游戏往往拥有少量的人物对话或者情节介绍的文本。可能会出现文本调用错误，或者是对话内容和情景不符方面的问题。另外文本显示的方式比较单一，所以测试过程中比较容易判断。
测试方法:
最常出现的是文本出框或者出屏的问题，完全可以通过确定文本的位置，然后使用EXCEL公式来进行字数判断的方法来确定。其他文本问题基本完整通关1-2次就可以发现。
C级:
RGC(竞速类)，SPT(体育类)
分析:
代表作:F1，MOTO GP(RGC)，NBA Street(SPT)。这种类型的游戏往往并没有很多的文本，但是涉及到的专业术语比较多，容易出现专业术语用词不当的问题。另外这2个类型的游戏会比较频繁的使用图片字，即我们所说的美术字体。至于文本显示方式的问题，这2种类型的游戏大多采用的是比较单一的文本显示方式，辅以少量的滚动屏。因此RCG和SPT类游戏并不会给开发者和测试者带来太大的麻烦。
测试方法:
考虑到RCG和SPT类游戏的文本数量有限，所以可以采用的测试方法非常的广泛，甚至可以应用穷举法来确认每一条文本的正确性。对于艺术字没有什么简单的方法，逐条确认是最稳妥的。但是由于这2类的游戏文本显示方式比较单一，所以对文本框显示的测试依然可以通过判断文本的位置然后对同一位置显示的极限字符数进行估算的方法来进行判断。

B级:
PZL(益智类)
分析:
益智类游戏的代表:Brain Challenge系列，Sudoku系列。这种类型的游戏特色之处在于Coach的引入和时间同步的设计。益智类的游戏对话文本主要是出现在“Coach对话框”，这就使得大量的对话框文本出现覆盖，出框或者是语境不正确的问题。同时“时间同步”的引入使得Coach的对话情景需要符合玩家在现实中的时间。除此之外，益智类游戏的文本比较分散，图片和艺术字的应用非常多。
测试方法:
益智类游戏的测试难点在于对话框的测试。有时候由于程序设计的问题会出现自动换行失效，或者是图片覆盖了文本框这样的问题。所以在目前阶段穷举法是测试益智类游戏唯一有效的方法。

A级:
RPG(角色扮演)
分析:
代表作:New York Night系列，Might & Migic系列。大量的人物对白，剧情介绍需要符合不同国家不同地区的语言风俗，而且要做到符合情景。文本数量巨大导致比较容易出现程序调用出错的问题。艺术字的广泛应用使得多国语言的特殊字符出现显示的问题。文本的显示方法比较单一，多为可自动调整的文本框，这使得RPG的文本框debug不如SLG游戏那么复杂。
测试方法:
虽然面临种种挑战，但好消息是目前的RPG游戏基本上是按照一条主线辅以少量的分支的模式来设计的，这就意味着在付出一定时间的努力之后，测试人员是可以逐条的确认游戏中的文本的。当然如果这是一个庞大项目的话，可以使用单元测试的方法来节约时间。

S级:
SLG(策略类)
分析:
这次将策略类而不是角色扮演类的游戏定为S级项目，让我们来看看策略类游戏在手机平台上的代表项目:FM足球经理。
庞大的数据库，丰富的随机事件给玩家带来了超凡的游戏享受(相对于手机平台)，伴随而来的是开发者和测试人员的噩梦。庞大的文本使得文本的处理必须要小心谨慎，任何疏忽都有可能造成编辑上的错误。同时丰富的随机事件让通过完整的完成游戏来确认每一条文本的正确性变得非常困难，测试人员无法确认他们手中的文本是否会出现在游戏中，当然这很大程度上是由于许多文本是在随机事件中出现的，而显然通过穷举的方法来测试是不现实的。而随机文本的大量应用也很容易造成程序文本调用出错的Bug。优秀的界面设计建立在使用大量的艺术字和图片的基础上，这使得文本Bug的出现几率成倍的增加。其实SLG项目预警等级高出RPG游戏最重要的因素就在于随机事件这一因素上，不确定性使得逻辑关系变得非常复杂，这使得无论是开发还是测试人员对程序的修改、调试都处于一个相对困难的环境中。
测试方法:
面对这样一种几乎涉及到所有文本bug类型的游戏，必须要通过项目组、Gameplay组和文本组的通力协作才有可能将出问题的几率降到最低。因为存在项目制作时间的约束，所以在质量上需要有明确的Bug优先级顺序。低等级的bug可以在测试时忽略掉。

三、文本Bug的优先级问题
通常意义上，我们会将BUG按照严重程度划分为A，B，C三个等级（注意：这里的等级划分指BUG本身的严重程度，而非项目预警等级）。
A级：表示非常严重文本Bug，需要尽快修复
B级：表示主要文本Bug，尽可能的修复它会对项目有益
C级：表示次要文本Bug，如果有时间就修复它，如果没时间，此Bug可忽略
      随着测试人员越来越多，测试工作也越来越完善。但是，如何快速有效地追踪并修复Bug，仍然是摆在我们面前的一个主要困难。测试产品和追踪Bug 时最重要的是问题的定义，要清楚需要解决什么样的问题，确定Bug 的主次关系，挑选出最主要的问题，并先解决它们。例如，有些A级BUG可能会导致严重的逻辑错误，这时就要先修复它们，而另一些Bug 可能对项目的影响不大，或者出现的几率很小，就可以考虑不去修复。
没有任何一个程序没有Bug，也永远不可能找出并修复所有的bug。在修复了旧的Bug 的同时，往往又会产生新的bug。在项目开发的最后阶段，当不确定修复一个无关痛痒的bug是否会引起更严重的问题时，最好还是选择忽略掉它。在我们的开发人员发送给国外测试人员的BugReport反馈中，对Bug会有如下的标示：
Fixed: 表示bug已经由开发组修复。
Not Fixed:  表示由于一些原因此bug在本轮测试结束后还没有被修复。
Pending: 表示开发人员正在等待进一步的确认消息，将在确认后修复它。
WNF(Will Not Fix):  表示由于某些原因，这个bug将不会被修复。
NAB(Not A Bug): 表示这是出于设计目的，并不是bug，它不会被修正。
我们在测试时要注意，一定要优先尽力找出那些影响玩家游戏的Bug并确定他们是否得到正确的修正。而对于大部分对玩家影响很少、甚至根本不影响的Bug，则可以推迟修复，甚至不修复。

四、总结
先对未来的文本bug走势做一个小小的预测。面对越来越多的console平台项目，目前手机平台上的常规文本bug如出屏，覆盖问题会越来越少，取而代之的是大量的特殊字符显示问题和程序设计的问题。需要通过缩短单词来解决的文本bug会越来越少。
   因此，我们的测试方法也需要慢慢的改进。首先，最重要的是搞清楚导致每种bug的原因，同时需要逐渐的了解开发人员的工作方式，以及他们解决问题的方法。一个不熟悉开发流程的普通测试人员和对项目开发有完整了解的测试者相比，无论测试速度还是效率无疑都是最低的。同时，精通开发流程的测试人员还有一项巨大的优势，他们可以通过bug的现象来准确的定位发生错误代码的位置，同时他们了解各种bug的机理，可以准确的联系相关人员去修改。这无疑大大的提高了debug的效率。今后若能增加对测试者的系统培训，掌握一些基础的开发知识，这对将来多语言文本测试方法的转型大有裨益。

作者: fhlia 时间: 2010-8-3 23:29
受用了，感觉自己定义太狭隘了。

作者: 云层 时间: 2010-8-4 17:35
额，难道是GL的兄弟爆文档来了？

作者: cncnily 时间: 2010-8-4 18:03
还真没看见过这个难道这是炒作

作者: shajqiu 时间: 2010-8-4 18:26
好吧，花了3分钟walkthrough了一把。
至少不算炒作贴，说的很实在也很易懂。但这里所涉及的仅仅是多语言版本的文本测试。bug等级也只是框在文本测试中。
做本地化测试的同学很受用，但仅仅只是本地化而已。。。

期待楼主共享更多的文档，Gameloft测试宽度应该远不只这些吧。
5年前的Gameloft里楼主说的这些我信，
但发展到现在应该已经有开发过单机游戏了吧，不仅仅只是手机平台的多语言文本测试了吧？

作者: nobuo0908 时间: 2010-8-5 10:30
我们的云哥难道鸡冻了！？？？

作者: 云层 时间: 2010-8-5 10:37

我硬盘上有很多文档。。

作者: ftest00 时间: 2010-8-13 19:40

不错谢谢分享

作者: wskfkdm 时间: 2010-8-19 14:50
可惜的是只局限于文本上的东西，如果有更详细的就更好了

作者: jiazurongyu 时间: 2011-6-2 15:55
好帖子顶上去~

作者: shajqiu 时间: 2011-6-2 16:25
好吧最新消息;
gameloft QC部解散, 总部移至越南....

作者: gogo1231 时间: 2011-6-2 21:01
Gameloft不都是通过穷举法来测的文本的么？还能有什么方法？

作者: 云层 时间: 2011-6-3 17:12
额其实我在GL的群上也看到消息了，GL SH的QA部门解散，简单来说就是成本太高了不如人家越南便宜啊

作者: shajqiu 时间: 2011-6-5 01:42
收到N多GL同学的简历，能拉尽量拉。
下周有一位幸运儿到我这报道，
可惜没有时间参与面试，不知道货色怎么样。。。

作者: Sun.Lee 时间: 2011-6-26 22:35
其实真的很不错

作者: Bely_wen 时间: 2011-6-28 16:51
俺亲爱的GL就这么解散了，GL的兄弟们有在这闲逛的么

作者: lovealina 时间: 2012-1-13 14:48
嗯。。。对于初学者来说还是有点意义滴。。。

作者: mask1102 时间: 2012-3-19 13:41
GL SH的游戏测试部不是已经GAME OVER了嘛？

作者: 亚克西西 时间: 2012-3-20 14:29
5年前的GL 算是鼎盛的时候吧

作者: 舞动精灵王族 时间: 2012-3-22 16:33

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)