软件测试技术

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

《游戏测试精通》 第九章

第九章 数字化测试



正如每行代码中发现的缺陷数目一样,产品度量告诉你游戏代码是否适合发行的程度。度量测试能告诉你,你的测试行为和结果的效果和效率。有些基本的测试数据可以通过多种方式联合在一起,而这些方式能揭示重要的信息。可以从测试和测试员那里尽可能多地获取信息,并分析这些信息以使测试不偏离轨道。


9.1 测试进程


为了满足游戏项目的需求和目标,对于理解哪里是测试点和其目的何在而言,收集数据是重要的。数据和图表可以由测试主管和单独的测试者收集。但自己应负责收集。比如,为了估计游戏项目的任一部分测试情况的持续时间,请先估计一下需要进行测试的总量。这个数目涉及每个员工每天能完成的测试量,每个测试者在测试中实际所花的时间和多少测试需要重新进行测试的相关数据。


图9-1给测试团队提供了一系列数据, 以方便为每个新代码的发布进行测试。项目经理与测试主管一起, 估计每天需要完成12个测试,以之为基础,来规划需要多长时间.才能完成这一新发布的测试。 正如图9-2所示,实际用了13 天时间,比规划的进程滞后了。看起来在第五天进程开始减慢,但是该团队对他们能赶上进度这一点感到乐观。在第十天,他们似乎回归了目标,但在最后三天,他们再次偏离了目标,尽管从该团队重新调入和调出了一些员工。


为了了解实际情况,请收集测试员能够执行的测试和他们每天完成的测试量。这个信息可以列入一个图表里,如图9-3所示。总数表明一个测试员每天平均完成四个测试。


image.png


image.png


image.png


一旦知道了每个测试员每天的测试数据,就可以比较测试员在他们参与系统测试的工作日里的测试完成率。理想情况下,这个速率可以达到1.00。你实际收集的测试数目会实际表明:大部分测试员不能将100%的时 间花在测试上。这是真的,所以请不要期望测试员会将100%的时间用在单个任务上!基于不同的参与度,这样的衡量可以让你预测系统测试员能完成多少任务。有的测试员只用在他们所的分配任务上尽心尽力。而另一些人,如开发商兼测试员,质量评估工程师兼测试员则要兼顾不同的任务。收集有关测试团队成员的数据后,可以像如图9-4所示那样将这些数据进行汇总。


image.png


从图中的数据可以得出许多重要的结论。其中之一就是,假如测试员对诸如训练、会议、准备备忘录等之类的任务“负荷过重”了,那么一个全职的测试员可能只能最多将他或她大约75%的时间贡献出来,在一个长项目的过程中,则只有50%~60%。如果你指望测试员以外的人员一一例如美 工、开发商或质量评估——来帮助测试,那么你能期待他们的全职测试员的参与率就只有目前的一半了。使用图9-4中的数据,其时间大约是他们能得到时间的30%。你可以将这些估算方法可以用在自己的项目中。


同样地,通过将个人测试的工作量相加得到团队测试工作量,如果团队成员有100%的时间来执行测试,该团队却只能执行他们能做的测试的一半。在测试被完成之前,这个工作量能与你估计的工作量做比较,从而得出余下的工作B的确切数量。对于剩余:的125个测试,使用11个测试员组成的团队,你要完成的测试大约就是11个工作日。但是,现在你知道团队的工作量是多少,你用11除以46%得到余下的工作日是24,或差不多“正常的”五周。如果你承担这11天的本来工作量,若测试不能如期完成,而是推迟三周之后才被完成,那么结果就不言而喻了。


在回答诸如“你要多少人才能在星期五完成测试?”或“如果我让你再多做两个测试,你何时能完成?”之类的问题时,以上分析得出的结论是很有用的。况且,比起在令人恐慌的状态下(记住规则1....)来努力弥补一大堆测试来,每天多做一个测试而不至于偏离轨道要容易得多。回到图9-1, 你会看到,在一月八日那天,整个团队只落后目标六个测试。在之前的六个工作日里,每天多做一个测试就能让团队如期完成任务。如果短期内你能够做到不偏离测试轨道,那么你就能长期坚持。



相关内容

文章评论

表情

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