Book：Charles P. Schultz, Robert Bryant, Tim Langdell, Game Testing All in One（周学毛等译, 清华大学出版社）, Thomson Learning
- 测试技术
在Intellivision平台上有一款曾经的畅销游戏名为Astrosmash，由于程序员在开发时假设没有玩家能得到达到一千万点，因此他并没有编写处理得分溢出情况的代码。而当游戏发布几周后，就有一些顾客开始打电话抱怨，当他们得分超过9999999点时，得分显示的是负数、字母或非数字符号。而事实上，由于该游戏允许玩家以慢动作玩游戏，使其更易于积累到高分数，因而更易触发该缺陷。由此，该游戏的作者约翰·索尔得到了一个深刻的教训：用户总会让你吃惊。
理想情况下，玩家可能会希望开发者做完所有可能的测试工作，扫清所有可能触发的Bug；但事实上，由于开发周期、成本等因素，使得这成为一个不可能完成的任务，甚至潜在测试集本身的数量也不允许测试团队做完所有的测试。因此，他们创造了一些十分有用的测试设计技术，来帮助减轻测试的压力，以接近完美的测试。
1）组合测试：
可选择是游戏的一大魅力所在，如在典型的RPG游戏中，玩家可以选择人物的性别、职业、服装、武器、初始属性值分配和所属战斗阵营等。但是这诸多的可选配置就给测试团队带了一个极为头痛的问题。假设有2种性别（男、女）、2种职业（法师、战士）可供玩家选择，那么需要测试2（2×2）种可能组合；那么，如果额外地提供2种可选的服装（丝绸、皮革），就需要测试8（2×2×2）种可能。完全的组合测试是一个无比庞大的指数级增长，它既不现实也不经济。但其实，只要测试覆盖了足够的功能，就可以将测试集做得小一点。配对组合测试提供了这样一种可能。
配对组合测试的基本思路是将可选值进行配对，得到测试集必须符合的条件集，那么如果缩小后的测试集满足这些条件，就认为它是正确的。比如上文提到的例子，它的测试集必须符合的条件就如下图（左）所示，而下图（右）则是一个符合要求的测试集表格，但它只有4条测试路径，却涵盖我们所关心的所有可选功能。
事实上，对于任意的可选参数集，都能通过一些简单可循的步骤创建任意大小的配对表格，生成令人满意的较小的测试集。并且，有一些预先构造好的表格模板可供选择，只需要简单地替换参数名称和值就能生成你想要的测试集；还可以选择组合工具Allpair，自动生成测试集。当然，这些并不重要，重要的是配对组合测试的方法可以节省掉大量的时间，将测试员从重复的冗余的测试中解放出来，而将精力投入到其他更值得关注的地方。
不过，有时完全的组合测试是必要的，比如对于一些对游戏而言十分重要的特征值，但这通常只占总特征的不到10%。测试团队通常会选择混合的方式，即对关键特征作完全测试，对其他普通特征作配对测试。有时，10％关键特征会用掉80%测试路径，而90％普通特征却只能共享剩余的20%，但这是合理的，因为这些关键特征往往是全新的富有创造性的，同是也是最容易出错的。
2）测试流程图（TFD）：
与组合测试不同，测试流程图是从游戏者的角度来描绘游戏行为的一种方式。如果多个游戏或特性中有相同的行为，测试员可以重复使用TFD；且只要正确的游戏条件和行为没有改变，TFD就保持不变，由此生成的测试路径就始终有效。
TFD通常使用专门的开发制图工具处理和分析，它大致包括流程、事件、动作、状态、终结符等要素。一张较完整的TFD如下图所示：
TFD需要配合数据词典才能发挥功效。数据词典对TFD集中每个独特命名的初始元素提供了详细的描述，尤其对于do条目定义了需要执行的操作，对check条目定义了测试员所需检查的目标。如定义check条目DropSound为：检查该项目是否已做丢弃声音。
那么，TFD上的每一条路径就代表一个测试流程，可以通过简单地复制粘贴数字词典上对应的描述，获得一份详细的测试设计文案。对于测试路径有几种经典的可选策略：
a. 最小路径：这种策略生成覆盖TFD中所有流程的最小路径，即TFD中的每一个地方至少被经过一次。它的测试次数在众多策略中是最少的，但它带来的问题是由于路径较长，有时直到项目的后期，才能发现一些早就在测试路径中存在的问题。
b. 基线路径集：基线路径是一条从输入终端到输出终端的直接路径，在不重复或往返循环的情况下经过尽可能多的区域，由此往复直到基线路径集覆盖流程中所有的地方。它比最小路径复杂些，但能避免最小路径的延后发现缺陷的问题，不过，由于不同路径的区别操作可能造成最终发现的Bug成因暧昧。
c. 专家结构路径：这一路径只是一个基于专业人员的经验制定的测试路径，它不必涵盖流程中的所有地方，但一定一次或多次经过专业人员认为最有可能失败或出现问题的地方。它往往是具有偏见的，但却很经济合算。因此，专家路径经常会联合前两者使用。
测试流程图的方法对于测试游戏的状态转化、操作流程和其他可重复的功能尤其有效。
3）净室测试：
净室测试是从一种被称为“净室软件工程”的软件开发时间中提取出来的技术，其最初目的是在项目中运行软件，以进行平均无故障时间（MTTF）的测量。在游戏测试中，净室测试被用来解决游戏玩家在运行了许多时间后发现官方未公布的缺陷这一问题。它的目的在于发现、根除很有可能会被用户发现的缺陷。这些缺陷通常存在于玩家经常会使用到的游戏功能中，这也就要求测试团队按照一种玩家的方式去运行游戏的测试。
首先要获得各个游戏功能的使用率。这可能基于测试员研究游戏玩家而得到的实际数据，也可能来自于个人关于这款游戏如何运行的期望，以及游戏生命周期中可能存在的玩法的变化。但，通常有三种定义和获取的方式：
a. 基于模式：这指游戏的不同模式，如对战、RPG、多人等。不同模式的游戏针对的用户群不同，因此习惯、关注点、所需提供的功能都不尽相同，比如多人游戏的玩家可能会比单机玩家更多地在意玩家间的交互方式。
b. 基于玩家类别：Richard A. Bartle将多用户玩家分为四类，进取者、冒险者、社交者和杀手。他们所热衷于的游戏功能就很不同，冒险者很关心游戏的艺术特效和美景，而杀手才不在乎，他只要体验杀戮的快感就万事大吉了。当然，还有其他的分类，比如键盘杀手和自定义者，游戏世界和真实世界是一样的，各种鸟都有。
c. 基于现实：这种方式比较直接和直观，它通过记录玩家的偏好并统计，以用于进一步的测试和改进。
得到使用率后，就可以利用其去选择测试步骤、数值、细节，且把它们按顺序排好形成能反映出玩家用法的测试情况。比如在使用组合测试时，使用率高的选项就应当在测试集中占有较大的比重；而在使用流程图测试时，使用率高的地方就应当被更频繁地经过。
4）测试树：
测试树提供了一种可以很好地反映存在于游戏功能和原理之间的树形关系。通过沿各种不同的从树的定点到树的每一个终点的路径测试，可以检测这些结构的行为方式。在游戏测试中，使用测试树有三种不同的目的。
a. 测试用例树：它记录了测试用例和游戏特点、原理和功能之间的层次关系。这种测试已经成熟并且文档化了。每一次开发小组给测试者发送一个新版本，测试树就会被使用。测试者根据缺陷补丁或者版本中引进的新功能，决定其影响的范围以及要执行的测试。并且，测试用例树也很好地表型了游戏本身的构造方式。如下图所示，针对一款战役游戏给出了一个粗略的测试用例树。那么，当有关小型战斗游戏模式的代码被改动后，测试者就可以通过查看测试用例树明确地知道，他需要进一步地测试地图、玩家数量、种族、游戏选项和胜利条件等。当然，有时，这种检测可以是向上的，比如一张新地图的加入，就需要执行所有战役模式的测试。
b. 特征树：这种树用于反映游戏中的一些逻辑特征，或者说是游戏规则，典型地如RPG中常见的技能树、任务树和升级树等。特征树可以被很方便地翻译成测试文案，测试方法通常是通过替换每一个特征条件直到满足结论成立，这样，就能找到有缺陷的条件。如下图（左），给出了一个十分简单的技能升级的特征树，只有当人物的白魔法能力达到2级，同时黑魔法能力达到3级，才能修习蓝魔法。那么这一规则的测试就如下图（右）所示。
c. 设计测试树：这种树可以提高对一个复杂的游戏特征的理解，并且给潜在的混乱职能带来秩序，尤其是在关于与其他游戏规则，原理和职能交互作用的部分。测试员通过它生成测试用例，用以查明狭小范围内的游戏行为方式中潜在的缺陷。比如在RPG中，一种魔法会因为不同的人物、地点、武器和对象，而产生不同的伤害效果。那么，测试者就可以根据这些画出一个针对该魔法的树，修建无效的支路，最后依次执行所有的生成校验该魔法适当行为方式的测试。
5）随机测试：
随机测试（Ad Hoc Testing），有时又称综合测试（General Testing），是以一种较为主观的方法来搜索错误。这种方法认为，就算拥有最全面、详尽的测试计划和设计，依然可能会有疏漏；而随机测试，允许测试员作为一个个体，在对游戏执行系列客观测试的过程中，探测那些可能已出现过的调查路径。通俗地说，当测试员想着“如果我做#%&$，会怎么样？”时，随机测试提过了一个回答诸如此类问题的机会。
随机测试有两种主要形式，自由随机测试（Free Testing）和定向随机测试（Directed Testing）。
a. 自由随机测试：又称右脑测试，因为其是否直观和主观，是一种有专业游戏测试人员“即时”设计的“可与原始数据分离”的测试。这种测试往往需要锐利的眼光，一种游戏测试员的直觉；要求测试者在混乱中创造秩序，有目标有记录；并且始终保持孤身作战，这是自由测试的一个重要原则，避免集体审议，使得测试员保留个人作为玩家的特征，更容易发现一些违反直觉的游戏缺陷。
b. 定向随机测试：这种测试方法使得测试者像一个侦探般工作，它通常用于解决某一特定问题或者查找特定解决方案，通常是因为一个或多个测试员报告了游戏中一个“偶然的”死机情况但原因不明后开始的，比如回答“场景切换的时候有时会崩溃”。测试员会先就结果作出假设，再一个个地验证它们。这个过程十分依赖测试员的经验和敏锐的嗅觉。共享信息是必要的，因为这方便地切断一些别人尝试过的假设，帮助更快的解决问题。
6）性能测试：
游戏性能测试与上文提到的所有测试技术所关注的焦点均不同。它关注的是“游戏运行得好不好”，而不是“游戏是否能运行”。差别是明显的，并且前者似乎更加重要，而且往往是带有主观特性的。性能测试的大部分是指对游戏平衡性的测试，也就是“游戏会不会太难或者太简单”以及“游戏中的各个可选功能是否均有可选之处”等。测试员所需要做的，是尽量准确地描述游戏的不平衡点，而不是给出过于精确的改善意见。
还有一些性能测试可以通过外部测试进行，也就是给除了开发团队和测试团队之外的人玩，比如公司的营销部。这也就是我们经常看到的外部Beta测试，它包括封闭的和开放的。封闭测试的测试员经过仔细筛选，而开放测试通常在封闭测试之后进行，面向其他一些感兴趣的人群。外部Beta测试依赖于有效的管理，否则，会带来大量无用的数据。
好游戏取决于有创意的设计、严谨的测试和有力的营销。设计带来亮点，测试巩固亮点，营销贩卖亮点。虽然Bug是挖不尽的，但我们仍希望它是接近完美的。因此，如若没有deadline，测试团队的工作将是无穷无尽的。也因此，使得Time-critical的测试成为一项极为繁重的工作。这迫使业界总在探索更有效的测试技术，如何节约成本，如何避免遗漏，等等。缺陷触发、自动化测试、捕获/回放测试等技术相继诞生。那么，这样一个没有Bug的未来是否值得展望呢？答案犹未可知。
No comments:
Post a Comment