软件测试技术

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

《游戏测试精通》 第七章

第七章 测试阶段


电子游戏可以大小不等,小到可下载的于机游戏,需要数周就可完成开发,而大型多人在线角色扮演游戏的开发则需要几年的时间。不管游戏有多大和生产预期有多长,游戏的测试应该始终遵循相同的基本结构:


(1)试生产阶段

(2)测试的开题阶段

(3)alpha测试阶段

(4)beta测试阶段

(5)最后测试阶段

(6)发布证明阶段

(7)公布之后的测试阶段


就像悬念惊悚的情节,跟下一个游戏相比,每个情节出现得越来越快,兴奋(压力)更为加剧。图7-1的数据说明了一个很粗略的、假设的中期预算控制台赛车游戏的时间表。


image.png


以下各节介绍每个阶段,以解释为什么它对该项目而言重要,和为什么它与其他各阶段有显著区别。


7.1 试生产阶段


根据你在团队中的角色和你进入项目的时间,你可能会认为测试是在游戏的一个成功部分被开发之后的某一个时间开始的。事实上,测试始于项目开始之时。在开始阶段可能并没有人被称为“测试员”,但是项目的范围、设计和素材,从一开始就被提出,它们需要被评估、批评和改正。


许多发生在项目的早阶段的事情,将会为以后测试的好坏定下基调。这意味着项目本身的好坏,以及测试本身组织和实施的好坏。底线是,最好能在项目一开始,就将较多的努力和技术应用于测试活动来修正错误,而不是后来对其做更多的测试(和加更多的班),来努力修正它们,那么开发团队和测试团队就能早点儿回家休息。


不能直接测试游戏质量。游戏质量由代码、图形和被嵌入游戏代码的声音确定。测.试所能做的就是,告诉开发团队代码出什么问题了。较好、较早地测试能更快、更好地修正问题。


如果在项目开始,你在邮件里收到一张优惠券,上面说 “寄来这个优惠券,你可以节省项目开支的20%或更多”,你会使用它吗?如果当你在项目结束时才节省测试成本,就如同你有了那张优惠券却因为不想付邮资而未使用,所以请从一开始就规划好。


7.1.1 计划任务


几乎一个方案一被构思,测试计划就开始了。测试计划包括下面几个所示的任务。


1.决定测试范围


测试经理会详细查看设计文件、TDD和项目进度表,以确定“测试范围”文档,该文档内容包括需要多少测试资源——即时间、人力和财力一一来确保游戏的发布,表头表7-1扩充计划(请看下面的,“扩 充计划”表)。



扩充计划


下面是写在出版商的一个小计划上前的简短的测试范围备忘录,以给同年早些时候发布的实时系统(RTS)开发一个扩充包。


备忘录


递交:监制

来自:质量保证经理

关于: RTS扩充测试计划摘要


摘要


基于下面的假设,测试该扩充包得花费1 760小时:

· 50天的生产进度表。

· 四人的测试团队。

· 加班发放的10%的津贴。

· 不包含发布后的补丁测试的后发布。


测试单玩家模式(900小时)


大量的QA时间将用于测试新活动。因为这些游戏使命的故事模式是高度依赖脚本的,测试员的任务就是将这些脚本分开,以确保用户会有一个天衣无缝的、游戏经历。


因为开发者没有在游戏中设计标记,而且已保存的游戏无法可靠地展示以前的版本,因此,分力脚本会占用大部分测试时间。


测试多玩家模式(650小时)


多玩家测试的核心是:


(1)确保新单元和新标题设置的正确执行。

(2)调试新地图。

(3)调试“精简界面”(设计文档中有新功能的描述)。

(4)应力测试游戏的规模。

(5)应力测试团队的大小。

(6)应力测试游戏的长度(时间允许)。

(7)平衡测试。


因为扩充包包括12个新单元,我们只考虑平衡测试——如果新单元之一很重要, 我们就会全面测试。我们没有资源来为50多个已有的单元进行再评估。我们将依赖开发者的设计团队(和自游戏发布以来的得到的用户反馈),来微调扩充包的平衡。


测试矩阵(210小时)


因为这是一种个人电脑游戏,而不是控制台游戏,所以对测试而言就没有第一方的TRC元件。然而,基于许多由我们的经验和其他PC游戏出版商的标准发展而来的PC游戏标准,我们会提供最终发布测试的一个相似的基于标准的关卡。


我们会在游戏上运行下列标准矩阵:


(1)安装/卸载矩阵(强调与以前产品的互用性)

(2)视窗“gotchas’ 矩阵

(3)出版商的标准矩阵

(4)多玩家的连接矩阵.


当在扩充包中测试原游戏的每个新单元时,我们也会生产并运行所开发而来的单元矩阵。


兼容性测试(0小时)


●因为最小的系统需求跟原来游戏相比不需要改变,我们不需要第三方硬件兼容性实验室的服务。在正常的测试期间,在不同的硬件上、不同的内部实验室里,如果任何|与机器类型相关的bug突然出现,我们那时会评估兼容性是否得到了保证。


加班成本(待决定)


只有在不加班就会延迟产品的生产时,我们才计划加班。



2.任命测试主管


这不是无足轻重的事。测试主管的经验、个性和技能会对测试周期的行为有巨大的影响。这可能是测试经理在为项目做出的最重要的决定。测试主管必须是


●领导——能 够激励测试团队,能让他们专注和高效的工作

●团队指挥一一测试作为更大些的项目组的部分,能意识到测试的地位

●交流者——能够收集并清楚而简洁地表达信息

●外交官——能够处理出现(它们会出现)的冲突


测试经理或测试主管应该指定一个“副测试主管”,通常被称作“首席测试员”在很大的项目组里(例如,超过30个测试员),有几个首席测试员是很普遍的,可以让他们每个人带领一个 具体的子团队(例如,多玩家、职业模式等)。


3.决定阶段验收标准


在理想世界里,你根据为每一个测试阶段限定具体标准的合同、设计说明或生产计划来工作。但实际中并非如此。


测试主管应该利用任何可得的材料,为游戏的alpha、beta和最后版本写出详细的说明。通过为每个测试阶段确立清晰而明确的验收标准,你能避免项目后期来自组织内各部门的压力和冲突,例如你开始了一个beta 测试,但事实上它不是真正的beta测试。一旦测试经理批准了这些标准,它们应该传播给项目组的所有高级成员。


对每个测试阶段的验证计划而言必备的三个要素是:


●入口标准: 在进入一个给定的测试前,版本必须通过的测试系列。比如说,直到代码通过了alpha 入口测试,该游戏才 能被认为是“在alpha测试阶段”。

●出口标准:在完成一个测试阶段之前,版本必须通过的测试系列。

●目标日期:开发团队和测试团队致力于发布一个具体阶段的日期。


4.参与游戏设计检查


如前面章节所提到的,在项目开始,测试主管或首席测试员应该定期参加游戏设计检查。他们的角色不是设计游戏,而是与最新设计变化保持同步,以及向项目经理说明那些会导致技术挑战或使得测试的复杂化的特性。在游戏范围和设计方面的改变会导致测试范围和测试流程的变化,以及测试流程的改变,因此要事先打好预防针。


5.建立缺陷追踪数据库


这是个关键步骤。在这个步骤里,一个设计很糟糕的数据库,当每次有人用它时,就会浪费他人珍贵的几秒钟,而且在项目结束时,那些时间可以快速累加成几个工时——就是你希望能回转的工时!图7-2展示了bug数据库中的一个典型的表格——注意表格“bug type”一栏中的“Unexpected Result”意外结果,这种描述太笼统了。


测试主管和项目经理应该互相达到适当的许可——即允许哪个团队成员对哪一领域有编辑的权利。测试主管也应该问项目经理要一份开发团队成员的名单,给他们分派bug任务。分派”的领域中的测试主管、项目经理或其他任何人被允许查看新bug和进行评价,然后让团队中的合适人选去对bug调查和进行修正。一旦他们已经解决了bug, .他们就能把bug返回给测试主管,以便在下一个版本中能使修正得到校验。


image.png


对于bug数据库能否安置在内部服务器或在英特网上链接,最好是保存一些虚拟的记录和复核所有本地的或远程的密码和权限来确保数据安全。每一个访问bug数据库的人都应该有一个个人口令。基于人们在项目组中的角色(请参看下面的,“太多” 中的内容),测试主管能决定一个人可否编辑和访问某部分的权利。


改动太多


只可由测试主管编辑的缺陷追踪数据库(或bug数据库或“bug 基地”)不是很有用,因为他们一般都是静态的,不能传达非常细微的有关项目状态的信息。在bug基地中并不是所有的团队成员都能编辑每个领域。


在设计bug基地时,测试主管必须平衡项目组成员的需要,便于他们共同探讨特殊的缺陷,这与需要控制所有项目组成员的信息流同等重要。在开发者评论域或说明域,程序员需要能够评论或提问有关缺陷的问题,但是他们不允许通过将状态城变为“已关闭”来任意关闭bug.测试员需要能够在简略描述和完整描述领域中添加bug,但是他们没资格制定bug的分派权限。


下面是些建议:


●状态域(Status) 只能被测试主管编辑。该领域的默认值应该是“新的”,所以,当测试员进入bug时,在状态被变为“开放”或被分派给开发团队的一个成员之前,它们应能被测试主管检查到。


●严重性(Severity)应该能被测试主管或首席测试员编辑。请记住缺陷的严重性不同于它的“修正优先级”。测试员一般会对他们发现的缺陷充满热情。测试团队的领导会对其进行核对、并以客观方式给其分派一个严重性域。


●类别域(CategoryField)应该能由测试员输入,且能被测试主管或首席测试员编辑。这些城包括诸如游戏类型、级别、bug类型,再现率和任何有关bug的特定信息的细节。


●简略描述/完整描述应该能由测试员输入,且能被测试主管或首席测试员编辑。


●分派(Assignedto)应该能被测试主管和开发团队的任何成员编辑。测试主管一般会将新bug分派给项目经理,然后他会检查bug,并将其分派给一个特定的程序员或艺术家来对其进行修正。一旦bug被修正,那么要么是将结果提交给项目经理,以让他进行更进一步的检查;要么是将它提交给测试主管,这样在下一个版本版本中修正能得到校验,bug 能够被关闭。


●开发者注释(DeveloperComments)应该能被项目经理和开发团队中的任何成员编辑。


●优先级域(Priority) 应该能被项目经理和开发团队中的资深成员编辑。这主要有助于项目经理决定开发团队的成员优先进行的工作流程。


6.测试计划草稿和测试设计


当测试主管开始起草测试文件时,他对当前游戏设计的最新情况的详细的了解是很重要的。起草一个完整的测试计划包括定义什么测试类型将被完成,以及单个的套件和矩阵看起来像什么(请参见到第8章“测试过程”)。这是项目中你能把本书第五部分中.介绍的方法用于实践的好机会。请记住:重要规划可防止表现欠佳。


(1)测试计划


一个测试计划对测试组而言,其作用就像一个剧本。它识别与资源(员工、时间、工具和设备)相关联的测试组的目标和要获得目标而必需的方法。测试目标一般根据时间和范围来定义。它们可能从属于团队。测试的时间表通常以在游戏的最终发布之前的一个或更多的里程碑为目标。任何可能影响测试目标的风险,连同关于该如何处理那些风险的信息,在测试计划中都应该提供。测试计划的范围可以局限于游戏的一个单的子系统,也可以涵盖许多游戏特征和发布。如果游戏正在多个位置被开发,那么测试计划有助于限定哪些测试职责要被分派到哪个团队中去。附录C包含一个基本的测试计划大纲,本书合作站点提供了可用的测试计划模版文件的链接。


(2)测试案例


一个测试案例包含一个被一个或多个测试员运行的单个测试。每个测试案例都有-个明确的目的,该目的是测试案例描述的一部分。测试案例中也描述为了达到目的要做哪些操作。测试案例中的每一个单独的操作因测试标准的不同而不同。在测试计划中,测试案例被分担责任的每个测试员确认并为其制定文档。一个测试员的测试案例集合应该完全覆盖他或她负责的所有内容。


(3)测试套件


测试套件是一个以更详细的形式来描述相关测试案例的集合。测试套件给出了关于在这游戏里运行什么操作和每一步要检查的细节的逐步说明。对于手工测试或写代码来进行的自动测试而言,这些指令应该足够了。根据详细测试的详细程序,也可以不依赖前一个测试中所采用的步骤。理想的情况是,测试套件中的每次测试能被单独识别,并且能独立于其他测试套件而被执行。若将每个测试案例视为独立的章节,那么测试套件就是描述测试案例详细内容故事的一本书。



相关内容

文章评论

表情

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