软件测试技术

当前位置:首页 > 软件测试技术

《游戏测试精通》 第七章 续

7.4 beta 测试阶段


在alpha测试阶段结束之后,开发团队应该对他们正在开发的游戏有非常清楚的概念。在极大程度上,开发团队此时已经停止创造新代码和新艺术品,现在会将其关注点转移到如何使开发出来的游戏更完美。现在是该识别和修正剩余bug的时候。


尽管术语“beta测试”常常指外部人员测试,但只是说beta测试的早期阶段应该让团队以外的玩家来测试最终的游戏。真正的beta测试是报告bug并测试装载,测试的大部分是被beta测试以外的人员完成的。为了在补丁程序或续集中修复可能出现的问题,应继续将游戏反馈意见和建议记录下来。


7.4.1 beta测试入口标准


下面是针对控制台游戏的一些典型的beta测试阶段标准:


(1)执行所有的特征和选项。游戏是“特征完成型”。

(2)代码至少100%的通过平台TRC。临近beta测试结束时,游戏应该为平台制造商的“预验证”做好准备。这个过程允许平台制造商的QA团队检验游戏的最新TRC和对任何潜在的问题提出警告。

(3)游戏能在所有的路径.上通过。有可能隔离游戏的各个部分的任何bug都要被清除。

(4)整个用户界面确定为最终版。

(5)游戏与所有指定的硬件和软件配置的兼容。

(6)游戏逻辑和人工智能确定最终版。“ 游戏机制”完整。游戏有其自身的规则。所有的人工智能完整性。

(7)所有控制器都运转。开发团队(和出版商)已经选择的那些第三方外设都有游戏支持。

(8)美术部分最终制作完成,不存在未完成的美术工作。Beta阶段是这样一个阶段:在此阶段,大多数的屏幕截图、追踪器和运动镜头都会被拿在包装中使用,并在在市场上销售游戏。

(9)最终音频制作完成。所有的未完成的声音片段已经被声音的最终素材所取代。

(10)所有的在线模式是完整的和可测试的。

(11)所有语言版本的文本得以实现,而且为同时的发布做好了准备。游戏脚本(既包括书面的又包括口语的)是锁定的,并可以转化并整合到游戏的外语版本。


7.4.2 设计锁定


在beta测试期间的某一时间点,项目经理应该宣布游戏处于设计锁定的状态(有时又称为特征锁定)。此时游戏大方面的测试已经结束。平衡问题得到了最好的解决。此时,测试团队关注的应该是,反复的通过实际测试案例来检验版本,因为此时每个已修正的缺陷可能会在游戏的其他地方引入另一个缺陷。


临近beta阶段结束时,要做出许多艰难的决定。团队很累,动不动就会发脾气,而时间即将被用完。在这种紧张的气氛里,他们几乎没有时间睡觉,项目组领导则要做出如下重要决定:


●是否要执行最后时刻的特征强化。在最后-刻,设计师可能有一个伟大的构想,渴望引入一个新特征、人物和关卡。项目组领导必须权衡执行新特征的风险(和可能引入的新bug和延期问题),来核对是否能及时交付一个也许不太紧迫的游戏。


●是否要砍掉似乎不那么有趣的关卡。有时,当一个关卡或其他内容成分问题太多太费力时,需要考虑是否干脆删除。但是,将其完全删除可能会带来问题,因为游戏需要新测试,以便剩下的关卡围绕已删除的特征而完全连续地运行,将其完全剪掉可能是个问题。关键事信息可能已经呈现在有问题的关卡,而关卡则不得不被重新编写(和重新测试)以适应这一点。


●哪些 bug将被忽略。从许多方面来说,这是所有决定中最难决定的——那就是哪些bug可以忽略。


7.4.3忽略 bug


身为一个玩家,你可能在你购买的游戏中已经遇到过缺陷。你的反应可能是,“测试员是怎么会没发现这一缺陷呢?”其实很可能是他们发现了但并没有修复而已。


有很多次,尤其是在项目后期,开发团队觉得他们不能(或不会)修复bug。这存在许多原因。也许是修正中的技术风险会超过缺陷的负面影响。也许会有一个技术上的支持团队能为遇到缺陷的游戏者提供帮助。也许根本就没有时间了。


不管是什么原因,每个项目必须有一个快速而有秩序的进程,以确定哪些缺陷不会被开发团队修复。不会被开发团队修复的bug通常采用下面的名称,asis(照现在的样子)、ISV(发布版)、DWNF(开发商不会修正)或CBP(已被生产商关闭)。对于这种情况,我遇到的最差的称号是“特征的(featured)”,这像个笑话,“它不是一个 bug,而是一个特征。”


对于开发团队没有(不能)修复的bug 不要有消极、极端的情绪。一方面,测试员工作很辛苦,要肯定自己的努力对项目而言是重要的。另一方面,开发商工作时间很长(如果不是更长的话),他们有责任按时将他们的游戏发布。至关重要的是,所有各方要理解和尊重每一个成员在整体项目组中的作用。理想的情况是,项目组的资深成员将定期开会,经常讨论这些开发团队不会修复的bug。在bug数据库的状态域或开发商状态域中,这些可标记为“请求取消”或“请求保留原样”。项目组的成员(生产商、执行生产商、测试主管和QA经理)一起开会来评价每个bug和讨论在游戏中修正它和保留它的正面和负面影响。其他团队成员,如程序员或测试员,应在必要时举行这些会议。这一决策机构有时被称为CCB(变更控制委员会)或bug委员会。


在有些案例中,期望一个后发布的软件更新或补丁,在游戏已发布后(请参看本书后面的“公布之后的测试阶段”这一节),许多bug将被指定要做修正。然而,在大多数的控制台游戏中,并不是这样的。


一旦bug被忽略,重要的是要让团队中的人知道该bug已被放弃,并不意味着它不是一个合法的bug。也不意味着他们不应该继续发现同样的缺陷。测试团队的作用就是每次详细记下每一个bug,不管是在周期中的那个阶段找到缺陷的。他们有义务将有关游戏状态的可能的最佳信息提供给测试主管、项目经理和业务部门的领导们,以便能做出最佳的商业决定。


7.5 最后测试阶段


一旦beta测试阶段停止,游戏应该处于以下典型的发布状态:


(1)所有的已知严重性为一级的bug(崩溃、暂停、主要功能失灵)被修复。

(2)所有超过90%的已知严重性为二级的bug被修复。

(3)所有超过85%的已知严重性为三级的bug被修复。

(4)任何已知的公开问题有专门的技术论坛(或记录在README.TXT文件中,针对PC游戏)。

(5)已达到发布要求的表现(60帧/每秒的帧率)。


一旦符合发布标准, 游戏被宣布处于“代码锁定状态”。接着进入一个短而紧张的测试时期,此时团队中的成员都希望得到(却可能不会是)最终版本。既然游戏最终版本叫做正式版,被测试的最后少数几个版本即是正式版的候选版本(GMC)或者发布候选版本。


从这一点来说, 游戏的各种版本与它的任何零售版相似。这就取决于测试员,通过寻找任何剩下的对游戏者体验有巨大影响的隐藏缺陷,测试员充当游戏者和项目组的最后防护线。这应当以最后一次重新运行所有测试套件的或时间允许时尽可能多次执行测试来完成。此外,许多测试员还应最后一次试图“拆散”游戏。任何在最后阶段中发现的严重缺陷都被称为“showstopper"(原指因特别精彩而被掌声打断的表演,这里指重要的缺陷),因为它导致正式版的候选版本被拒绝。一个新GMC一定要准备好对新缺陷的修正,且发布测试必须从头再做一次。


最后时刻的缺陷


由于项目的最后阶段十分紧张和充满压力,因此人们将会对特别受欢迎之物产生消极反应:“ 为什么我们(或你们)现在才发现这个bug?测试已经持续了长达数月之久!”这一重复的话时常能从心力交瘁的经理们那里听到。


测试团队最好是大踏步地前进以平息情绪化的评论,记住在游戏开发中神圣不可侵犯的几个真理:


(1]) 对于任何项目,都很少有充足的时间找出所有缺陷。

(2)程序员触及代码,缺陷就可能被引入。.

(3)代码随时间累积而变化,以至于游戏不同部分的几个重复变化导致了这些变化的后期出现的bug。

(4)临近项目结束时,程序员更加疲惫且易出错。

(5)临近项目结束时,测试员更加疲惫且容易遗漏事情。

(6) bug发生。


在PC游戏中,一个出版者或融资实体永远是一个网络游戏或任何其他的游戏能否公布产品的唯一仲裁人。 一旦黄金测试的阶段已经结束,游戏就准备投入生产。然而,在控制台游戏的情况下,需要对代码进行最后的验证。这最后的程序验证被称为发布测试。


7.6 发布证明阶段


一旦项目组已经完成黄金测试,一个完好的GMC就被送到平台制造商进行最后一次验证。平台制造商(例如,任天堂、索尼电脑娱乐美国公司或微软)会对GMC进行周密的测试。其测试分为两个阶段,这两个阶段可以同时或连续发生。标准阶段测试,通过测试代码来验证是否符合TRC。功能性阶段测试,测试代码的功能性和稳定性。发布测试员对每次提交总是至少从头至尾地将游戏玩一遍。他们往往自己能发现特别精彩的bug。


验证测试结束时,平台供应商的QA团队会发布一个他们在GMC中发现的所有bug的报告。出版商代表将会与平台经理的客户代表就bug进行讨论,双方将决定清单上的哪些bug必须被修复。


开发团队被建议只修复那些在“必须修复”的bug,并避免修复清单上的每个小bug,以满足平台制造商的需求。修复的bug超过“必须修复”的bug时,只会使代码仍处于危机中。


一旦游戏再次提交并已经被平台制造商认可,那么它就成为“正式版(Gold)”。现在可以开香槟庆祝了。但是项目却仍然还没结束。



相关内容

文章评论

表情

共 0 条评论,查看全部
  • 这篇文章还没有收到评论,赶紧来抢沙发吧~