May 30, 2010

[读书笔记] 游戏测试 Part 2:测试技术

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. 测试用例树:它记录了测试用例和游戏特点、原理和功能之间的层次关系。这种测试已经成熟并且文档化了。每一次开发小组给测试者发送一个新版本,测试树就会被使用。测试者根据缺陷补丁或者版本中引进的新功能,决定其影响的范围以及要执行的测试。并且,测试用例树也很好地表型了游戏本身的构造方式。如下图所示,针对一款战役游戏给出了一个粗略的测试用例树。那么,当有关小型战斗游戏模式的代码被改动后,测试者就可以通过查看测试用例树明确地知道,他需要进一步地测试地图、玩家数量、种族、游戏选项和胜利条件等。当然,有时,这种检测可以是向上的,比如一张新地图的加入,就需要执行所有战役模式的测试。
            20105301632013
    b. 特征树:这种树用于反映游戏中的一些逻辑特征,或者说是游戏规则,典型地如RPG中常见的技能树、任务树和升级树等。特征树可以被很方便地翻译成测试文案,测试方法通常是通过替换每一个特征条件直到满足结论成立,这样,就能找到有缺陷的条件。如下图(左),给出了一个十分简单的技能升级的特征树,只有当人物的白魔法能力达到2级,同时黑魔法能力达到3级,才能修习蓝魔法。那么这一规则的测试就如下图(右)所示。
            20105301642134    20105301642333
    c. 设计测试树:这种树可以提高对一个复杂的游戏特征的理解,并且给潜在的混乱职能带来秩序,尤其是在关于与其他游戏规则,原理和职能交互作用的部分。测试员通过它生成测试用例,用以查明狭小范围内的游戏行为方式中潜在的缺陷。比如在RPG中,一种魔法会因为不同的人物、地点、武器和对象,而产生不同的伤害效果。那么,测试者就可以根据这些画出一个针对该魔法的树,修建无效的支路,最后依次执行所有的生成校验该魔法适当行为方式的测试。

    5)随机测试:
    随机测试(Ad Hoc Testing),有时又称综合测试(General Testing),是以一种较为主观的方法来搜索错误。这种方法认为,就算拥有最全面、详尽的测试计划和设计,依然可能会有疏漏;而随机测试,允许测试员作为一个个体,在对游戏执行系列客观测试的过程中,探测那些可能已出现过的调查路径。通俗地说,当测试员想着“如果我做#%&$,会怎么样?”时,随机测试提过了一个回答诸如此类问题的机会。
    随机测试有两种主要形式,自由随机测试(Free Testing)和定向随机测试(Directed Testing)。
    a. 自由随机测试:又称右脑测试,因为其是否直观和主观,是一种有专业游戏测试人员“即时”设计的“可与原始数据分离”的测试。这种测试往往需要锐利的眼光,一种游戏测试员的直觉;要求测试者在混乱中创造秩序,有目标有记录;并且始终保持孤身作战,这是自由测试的一个重要原则,避免集体审议,使得测试员保留个人作为玩家的特征,更容易发现一些违反直觉的游戏缺陷。
    b. 定向随机测试:这种测试方法使得测试者像一个侦探般工作,它通常用于解决某一特定问题或者查找特定解决方案,通常是因为一个或多个测试员报告了游戏中一个“偶然的”死机情况但原因不明后开始的,比如回答“场景切换的时候有时会崩溃”。测试员会先就结果作出假设,再一个个地验证它们。这个过程十分依赖测试员的经验和敏锐的嗅觉。共享信息是必要的,因为这方便地切断一些别人尝试过的假设,帮助更快的解决问题。

    6)性能测试:
    游戏性能测试与上文提到的所有测试技术所关注的焦点均不同。它关注的是“游戏运行得好不好”,而不是“游戏是否能运行”。差别是明显的,并且前者似乎更加重要,而且往往是带有主观特性的。性能测试的大部分是指对游戏平衡性的测试,也就是“游戏会不会太难或者太简单”以及“游戏中的各个可选功能是否均有可选之处”等。测试员所需要做的,是尽量准确地描述游戏的不平衡点,而不是给出过于精确的改善意见。
    还有一些性能测试可以通过外部测试进行,也就是给除了开发团队和测试团队之外的人玩,比如公司的营销部。这也就是我们经常看到的外部Beta测试,它包括封闭的和开放的。封闭测试的测试员经过仔细筛选,而开放测试通常在封闭测试之后进行,面向其他一些感兴趣的人群。外部Beta测试依赖于有效的管理,否则,会带来大量无用的数据。

好游戏取决于有创意的设计、严谨的测试和有力的营销。设计带来亮点,测试巩固亮点,营销贩卖亮点。虽然Bug是挖不尽的,但我们仍希望它是接近完美的。因此,如若没有deadline,测试团队的工作将是无穷无尽的。也因此,使得Time-critical的测试成为一项极为繁重的工作。这迫使业界总在探索更有效的测试技术,如何节约成本,如何避免遗漏,等等。缺陷触发、自动化测试、捕获/回放测试等技术相继诞生。那么,这样一个没有Bug的未来是否值得展望呢?答案犹未可知。

May 29, 2010

[读书笔记] 游戏测试 Part 1:基本概念

Book:Charles P. Schultz, Robert Bryant, Tim Langdell, Game Testing All in One(周学毛等译, 清华大学出版社), Thomson Learning


为着这学期软件工程课8000+字的Term Paper看的这书。前日去图书馆原是想借些正经软工书的,翻了满架子的书竟是本本写得都像畅销书,还真如众人所说的,真水。想看些架构设计的书,竟也没找着。稍有些质感读起来也不太枯燥的,就只有一些游戏方面的书,有图,还有些我知晓的例子。那便看吧。

测试为什么重要呢?因为游戏会出错,出各种各样的错,并且即使经过了漫长的尽可能全面的测试,游戏依旧会出错。但这恰恰说明在发布前的测试是十分必要的,不管是对于游戏出版商,还是对于开发团队而言。一款出色的游戏会得到褒奖,而一款充满Bug频频跳闸的游戏则会给开发团队带来漫天的骂声,销售额和利润也随之蒸发。

测试为什么对于游戏尤其重要呢?其实测试对于任意一款应用软件都是相当重要的,但是没有一款应用软件像游戏这样拥有庞大、多样、富有压力的客户群。不要指望玩家规规矩矩地按照手册上写的点击菜单,你永远都无法完全预测到每一个玩家所有可能的变态操作——他们可能在物品交易的过程中突发奇想地丢掉正在交易的物品,而导致玩家数据错误。因此,游戏测试是任重而道远的。
 

  • 游戏测试员的任务
    作为一名出色的游戏测试员,需要从一名游戏玩家开始,但绝不仅止于此。游戏测试员需要诀窍来发现问题、记录并报告Bug、报告测试进展和帮助开发者发现并确定Bug具体位置。在游戏发布之前,测试员需要反复地做以下这些事情:
    201052710520821 

    1)Play:游戏测试员的“玩”较普通玩家是少有选择性的,测试方案从一开始就规定了测试的目的和步骤,如查探某一游戏中的地图、检查某个特定的原则是否得到执行、或者寻找某一类特殊的问题。有些测试甚至是十分具体的,比如对游戏界面的测试,就依赖于敏锐的观察和对细节的注意,并且往往需要循环重复一些枯燥的按钮和下拉动作,以确定是否存在某些不合理或错误的操作响应。

    2)Identify:游戏测试有两个目的,一为找到游戏代码或设计中的缺陷,二为说明游戏中的各个部分能否正常运行。当在测试过程中发现了问题,游戏就相对地“失败”了,这时需要测试员详细地描述发生该问题的过程和结果。
    当测试游戏的同一部分时,不是每个测试员都能发现同样的缺陷。心理学上认为这是由人的不同性格造成的,并给出了有效的性格测试工。这个工具可以识别一个人是裁判还是感知者。裁判善于组织和作计划,喜欢井然有序和可预测的测试环境,专注于测试内容的细节,提供详尽的测试报告,适合测试用户手册、脚本;感知者则喜欢采用非常规的游戏玩法,测试多种可能和游戏的真实体验,往往不受计划约束,却能发现一些意想不到的珍贵Bug。这两种人是互补的,因此在一个测试团队中往往需要这两种人。

    3)Amplify:这里的“放大”指的是尽可能地使缺陷在第一次被发现时就完全暴露出来,以减少用在这个问题上的时间和成本,这对开发者通常是有益的。为了达到这个目的,通常需要做到两点。首先,尽可能早地执行测试,如当一些新的人物、关卡、功能或子系统第一次被引入时就应当马上进行测试;第二,当在测试过程中发现某个Bug时,应当检查每一个可能触发该Bug的地方,如代码中所有调用包含缺陷的关卡、功能或子系统的地方。

    4)Notify:当测试人员发现问题且能描述它影响游戏的方式时,就需要记录此信息并就此向开发人员通报。这一过程通常通过缺陷追踪和管理软件实现,如业界常用的DevTrack。一份完整的通报包括以下几个重要部分:

    a. 标题:一个描述性强的标题通常很有用,它帮助开发人员快速地定位此缺陷的大致内容。好的标题通常需要包括一些重要的要素,如事件、人物、方式等。这就和撰写报纸的标题一样,像“杭州地震了”这样的标题是不适用的,它让人产生迷惑。而“5月22日杭州发生里氏8级大地震”这样的标题则合格得多,它恰当地表达了这则新闻的重要性和爆炸性。有时还需要更多的细节,如“造成90人死亡”和“城中30余处房屋倒塌”等。

    b. 描述字段:这里包括测试员能及的所有有帮助的细节,人物(战士)、事件(嵌入到内墙的上部)、地点(训练厅)、时间(拜访符咒训练者后)和方式(跳跃)。有时,如果可以,还会描述问题可能的解决方法等。

    c. 缺陷的优先级:优先级的名称和含义对项目而言可能各不相同,但概念是相同的,都是根据其重要性对缺陷进行划分,从而决定它是否被优先处理。“紧急”的Bug可能导致玩家信息的丢失、终止或异常中断游戏等重大缺陷;一个“高”优先级的Bug通常是导致某些严重后果的缺陷,如提交了请求但不能得到请求的东西;“中等”缺陷导致明显的问题,但不会危及玩家的奖励或关卡;“低”优先级的Bug则是正对非常微小的缺陷而言,如一些不容易发觉的拼写错误。但应当注意的是,Bug的严重性等级和优先级是有所区别的,比如主菜单中的拼写错误并不会导致什么严重的后果,但却是一个急需改正的Bug。因此,大多数游戏公司会在对Bug订正排序时联合使用严重性和优先级。

    d. 缺陷的类型:包括需求修改、文档问题、矛盾报告、进一步增强、微小改进、新特征、第三方错误等,对确定缺陷的路径和处理缺陷而言有重要的意义。通常缺陷管理软件会提供一些可选的分类。

    e. 备注:这确保测试员通过添加文件的形式,提供所有有帮助的内容或信息,包括日志文件、包括Bug的录像、操作系统的弹出窗口和错误代码等。

    5)Testify:游戏测试员的工作只是发现并通报缺陷,而真正区分缺陷的优先级的权利则掌握在变更控制委员会(CCB)手中。CCB监督和促使最要紧的缺陷得以完成修复,从而在项目期限到时能交付一个最符合要求的游戏。其成员一般包括来自发展部门、测试部门和项目管理部门的代表,他们对Bug进行仔细检查,对其优先级打分,再交付修改。值得一提的是,这里涉及到游戏测试中另一个重要的原则——有选择的(Optional),有时因为项目期限的临近,使得许多团队放弃修复一些有难度的缺陷。

    6)Verify:这一步指的是在Bug被修复好之后,有测试人员再次对性测试一次,以确定其是否被完全和有效地改正。
     
     
  • 游戏缺陷的类型
    由IBM公司开发的正交分类(ODC)系统定义了多种软件缺陷的分类方法,其中与游戏较相关的大致有八类。每一种缺陷类型或者是执行结果不正确,或者是缺少代码。

    1)功能(Function):功能错误是一种影响游戏性能及用户体验的错误,可能由提供这一功能的代码丢失或不正确造成,如,在触发某一人物技能后,显示技能停留剩余时间的时间条的缺失。

    2)赋值(Assignment):赋值错误指程序所使用的值被错误地初始化或设置,多数发生在游戏开始、进入一个新关卡或一种游戏模式时,典型地如在策略游戏中,对开始的位置单元和可用资源的初始化。错误的赋值将导致对游戏平衡性的破坏。且有时这种错误是隐藏的,难以有程序员发现的,只有通过测试才能找到。

    3)检查(Checking):当代码在被使用前缺少适当地验证数据时,就可能产生检查类型的缺陷,简单地如边界比较,使用<=代替<。

    4)时间控制(Timing):时间控制缺陷与资源的共享、资源的实时管理相关。良好的时间控制应当在加载某些大型资源时,给出进度条,显示正在进行的操作。通常RPG游戏中在人物启动某项特殊技能的时候会给出一个短小的动画,但往往技能切换完成得会比动画快得多,这时错误或缺失的代码讲导致在动画完成前,技能就被启动,这是违反游戏的世界观原始设定(比如关于念魔咒隐身),这是一个典型的时间控制缺陷。

    5)构造/包装/合并(Build/Package/Merge):这类缺陷是由于配置游戏源代码库系统,变更游戏文件管理,或版本识别和控制引起的错误。良好的版本管理和习惯约定能减少或避免出现这类缺陷。

    6)算法(Algorithm):算法缺陷包括一些计算过程或者选择结构中出现的有关时间复杂度或正确性的问题,主要涉及逻辑控制、AI、数值计算、渲染控制等方面。这类缺陷都大部分涉及到游戏功能,其中一些还是隐藏功能,因此大多会考虑写一个专门针对某一算法缺陷的查找脚本,做连续地测试,而不是一个一个地手动测试。

    7)文档(Documentation):文档缺陷不是由不适宜的代码导致的,而是存在于从文件中重新得到的字节型数据或定义的常量,比如在屏幕上显示的文字、音频或供函数调用的读入参数。这些缺陷只能通过仔细地阅读文本、听音频、检查文件和图形,才能被检测到。

    8)接口(Interface):接口缺陷可能在任何一个信息被转移或交换的地方发生。但通常,它的存在是由于模块之间的调用方式有误,比如被传入的参数与调用例程不匹配,或者在传入时使用前没有做合适的数值范围或类型检测等,都可能导致接口缺陷的产生,而且这些缺陷往往是细小且不容易发现的。
     
     
  • 测试阶段与过程
    虽然游戏的大小不等,开发周期也各不相同,小到只需数周就可完成的手机游戏,大到一些大型的MMORPG或平台游戏,有时需要几年的开发时间,甚至屡屡跳票(如暗黑3)。但不管游戏有多大、生产周期有多长,其测试始终遵循相同的基本结构。

    1)试生产阶段:对测试可能的认知是认为测试是在游戏的一个成功部分被开发之后的某一个时间开始的,但事实上,测试始于项目开始之时。许多发生在项目的早阶段的事情,将会为以后测试的好坏定下基调。最好能在项目一开始,就将较多的努力和技术应用于测试活动来修正错误,而不是后来对其做更多的测试,来努力修正它们。
    在这一阶段,需要制定合理的测试计划,包括:决定测试的范围、任命测试主管、决定阶段验收标准、参与游戏设计检查、建立缺陷追踪数据库(关键)、起草测试计划草稿和测试设计。除此之外,还要对游戏原型作模块测试,并且根据测试要求招募或雇佣额外的团队成员。这一阶段的测试结果往往是不成熟的,但却对未来的测试工作有着深远的影响。

    2)测试的开题阶段:这一阶段分为两个部分,测试员准备和开题会议。测试员准备的步骤和开题的议程都记录在测试开题的清单上,可以看到,测试员需要在开题前通过阅读说明书或文档了解被测试的游戏特征,需要测试所需的设备、文件和程序,最后需要阅读由测试专家书写的测试文案。
    开题会议是一个交互式的会议,每个测试的开题都是改善对测试的理解、测试质量和测试执行的机会。通过会议当中的讨论,能提前发现一些在未来的测试过程中可能遇到的问题,并找到补救措施。有统计表明,开题会议实际上节约了测试时间,开题测试的速率是非开题测试速率的1.4倍。

    3)α测试阶段:在α阶段的游戏是成型的,游戏的特征已经被测试和校订了,各种素材也被整合过了。这是整个游戏第一次完备的测试,因此,这一阶段的测试是最繁忙的,也因此严格坚持测试套件中的内容是十分关键的,它能让整个测试过程井然有序。在α阶段,游戏的所有模块至少应该被测试一次。业界有公认的详细的α阶段测试入口标准,涉及代码的平台TRC通过率、QA要求、软硬件相容指标和美术要求等,只有符合该标准才能进入α测试阶段;类似的,也有β测试入口标准和最终测试入口标准等,这对整个游戏的测试阶段起到良好的规划作用。

    4)β测试阶段:此时,开发团队已经在极大程度上停止创造新代码和新素材,而将关注点转移到如何使游戏更完美,也就是到了识别和修正Bug的时候了。在β测试的早期阶段,会有团队以外的玩家参与测试,但大部分的时间会被花在报告Bug并测试装载上。
    这里有一个值得一提的时间点,称为“设计锁定”。当设计锁定状态被宣布后,游戏大方面的测试都已经结束,平衡问题也得到了最好的解决,团队的关注点变为反复地通过实际测试案例来检验版本。在这一状态到来前,项目组需要作出一些重大的决定,如是否要执行最后时刻的特征强化(引入设计师的新构想)、是否砍掉似乎不那么有趣的关卡、哪些Bug将被忽略(难以决定,但时间是有限的)。

    5)最终测试阶段:进入这一阶段的游戏出于典型的发布状态,所有的已知一级Bug(崩溃、暂停、主要功能失灵)和大多数的二级、三级Bug被修复。游戏被宣布处于“代码锁定”状态,测试员充当游戏者和项目组的最后防护线。测试团队将最后一次,在时间允许的条件下,尽可能多次执行所有测试套件。任何在最后阶段中发现的严重缺陷都将导致候选版本被拒绝,Bug修正后最终测试必须从头再做一次。此时,整个团队都处于极度的疲倦中,但唯有大踏步地前进才是最好的取得胜利的方法。

    6)发布证明阶段:这一阶段的测试通常是由平台制作商(任天堂、索尼)来完成的。其测试游戏的代码是否符合TRC,其功能性和稳定性是否合乎标准。通常,此时还会有一些Bug被发现,然后开发商将会与平台经理的客户就Bug进行讨论,开发团队将被要求修复那些“必须被修复”的Bug。这一过程有时会反复多次,直至候选版本被平台制造商认可,成为“正式版”。

    7)公布后测试阶段:游戏发布后,测试依旧不会停止。这也就是我们通常看到的开发商不断公布补丁的时刻,但并不是所有的补丁都用于修复Bug,有时它们是用来为游戏添加新特征的。这一过程会一直持续到游戏的生命周期结束。