软件测试技术

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

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

8.3.7 报告结果


写好bug报告是测试员应该掌握最重要的技能之一。只有当一个缺陷表述得既清楚又有效时才有可能被修正。软件开发中的最老的笑话之一类似于 下面这个:


问:“需要多少灯泡?”

答:“不需要——程序员待的地方不黑。”


要写好一个bug报告,程序员要能在bug中“看到光明”。但是程序员决不是报告的唯一读者。读者可能包括


●测试主管或首席测试员,他们可能希望在bug数据库中给bug一个“公开的”优先级之前,能阅读该bug的有关说明。

●根据bug描述为组员分派任务的项目经理。

●负责衡量修正(或不修正)bug可能产生商业影响的市场营销主管或其他商业主管。

●例如像中间件的卖 主之类的第三方,他们可能被要求去检阅一个bug,该bug可能跟他们提供给项目组的一个产品相关。

●客服代表,他们可能被要求为bug设计工作区。

●测试员,回归测试期间,如果他们被要求验证一个修正,他们会复制这些步骤。


因为你从不知道具体哪些人会阅读你的bug报告,你必须总是尽可能清晰、客观和冷静地来编写报告。你不能假设任何阅读你报告的人会跟你一样对游戏已经熟悉。


比起工作于整个项目组的其他人而言,测试员在游戏上花的时间更多——探索每一个隐藏的路径,仔细检查每一份素材。一份写得好的bug报告会使不熟悉游戏的人很好地理解该报告所描述的缺陷类型及其严重性。


只有事实才重要


事实是,缺陷使开发团队压力重重,尤其是在“危机时刻”。数据库中每一个新增的bug就意味着更多的工作要做。一个中等大小的项目,在其完成前,会有成百上千或成千上万的缺陷报告。开发商会感到非常不安,反过来,如果他们感到时间被愚蠢的或虚无的bug所浪费,就会变得很仇视。这就是为什么好的bug报告既要以事实为基础又要没有偏见的原因。


警卫的帽子应该是蓝色。


这既不是缺陷也不是事实。这是对设计的一个多余而任意的观点。此类观点可以出现在与测试主管的讨论、团队会议、游戏测试反馈中,但是bug数据库中不包括。


在许多游戏中的一个共同问题是,人工智能在某种程度上是不足的(人工智能是个囊括一切的术语,用来表示游戏中电脑控制的对手或NPC所具有的智慧)。


人工智能是脆弱的。


这事实上可能是个事实,但是它以这样-种模糊而概括的方式写出来,以至于它可能会被人认为是一种观点。传达同样信息的更好的一个方法是,举例并描述一个特定的人工智能行为,而且快速的对这一特定的缺陷进行详细说明。通过将混乱的问题具体化,你可以将它们变成有很好的机会被修正的缺陷。


但是,在你开始写bug报告之前,你必须确定你找到了所需的所有事实。


简略描述


更大一点的数据库可能包含两个描述字段:简略描述和完整描述。简略描述是作为一个辨别bug的快速参考。这应该不只是一个醒目的副标,而是一个一句话的描述,能让团队成员不用每次都阅读更长的完整描述才能辨别和讨论缺陷。请参考作为缺陷报告的大字标题的简略描述。


崩溃后回到桌面。


这不是一个完整的句子,对简略描述而言,它也不够确切。它可能是数据库中很多缺陷的部分描述。简略描述必须足够简略,以便于易于并快速得被阅读,但是又应该足够,长到能清楚地描述bug。


用于保存的系统崩溃


这是个完整的句子,但不够明确。测试员经历了什么呢?是游戏没保存吗?是保存好了的游戏没上传吗?是保存导致了冲突吗?


当从主莱单选择“方式”时一下就回到了桌面。


这个句子完整且明确,以至于任何阅读它的人都会多少知道些关于缺陷的位置和严重性。


在我杀死了所有的警卫后游戏崩溃了,两次回到了尚未添加列表项的级别,并杀死了第一个重生的警卫。


这是个跨行语句,包含了太多的细节。能概括它的一句表述可能是


警卫重生以后游戏崩溃了。


报纸上的电视节目表能提供简略描述的经典例子——它们能将一个半小时的情景喜剧或两小时的电影压缩成一两句话。


完整描述


如果简短描述就是bug报告的大标题,那么完整描述就提供了具体的细节信息。这不是说要散文式地铺开来讨论缺陷,而是说完整描述应该包含一系列的简略描述,以至于任何人都能遵循这些步骤并复制出该bug。 这些步骤应该采用第二人称,就像你正在告诉某人要去做什么。最后一个步骤是用来描述坏结果的一两个句子。


(1)启动游戏。

(2)观看开始动画,不要按“ESC"键跳过动画。

缺陷:注意到开发标志中有不好的效果。


步骤越少越好,字词越少越好。请记住Ocean's Eleven中,布拉德·皮特对马特·达门的警告:“ 当四个字够用的话,就不要用七个字。


同样地,当四个步骤够用的话,就不要用七个步骤。开发游戏时,时间是珍贵的。程序员用来阅读和理解bug的时间越少,那么他留下来修正bug的时间就越多。


(1)启动游戏。

(2) 选择“多人模式”。

(3)选择“多人练习模式(Skirmish)”。

(4)选择“悲伤的海滩(Scorrowfull Shoals)”地图。

(5) 选择“两人游戏”。

(6)开始游戏。


这些都是非常清楚的步骤,为了简洁的缘故,它们就应该被压缩成启动悲伤的海滩地图上两个人练习模式的游戏。


但是,有时你需要几个步骤。下面的bug描述了一个有关“Mugging(抢夺)”道具的问题,它从部队抢夺了道具。有


(1) 创建一个与人对战的游戏,选择“Serpent”一方。

(2)派一个武士到会馆取得“Mugging”道具。

(3)用组件创建部队并赋予部队力量。

(4)让武士在地图中部的某个地方与他的部队会面。

(5)启动“Mugging”攻击装备。

(6)攻击对手的部队。

缺陷:武士攻击时游戏返回桌面。


这似乎可能像有很多步骤,但是这是重现该bug的最快捷的方法。每一步对隔离“Mugging(抢夺)”代码都很重要。甚至像“在地图中部的某个地方会面”这样的小细节都重要,因为在占领区会面可能引起同盟部队一方和另一方的战斗,而测试就不可能执行。


大期望


缺陷本身常常在完整描述的步骤中看来可能并不明显,因为这些步骤产生的结果偏离了用户的期望,但是不会产生冲突或严重的症状。有时给你的完整描述加,上额外的两行内容是必须的:期望结果和实际结果。


如果遵循bug中的步骤,期望结果描述一个普通玩家玩游戏的一般结果。这种是基于游戏,尤其是同类游戏中的测试员对设计说明、目标读者和先例集(或打破的)的基础之上给出的。


实际结果描述有缺陷的行为。下面是一个例子:


(1)创造多人游戏。

(2)单击游戏设置。

(3)用鼠标单击“地图”选择的任一地图。

(4)按向上或向下方向键。

(5)选择不同的地图,记住所选的地图。

(6)单击返回。

(7)单击开始游戏。

预期结果:加载了你所选择的地图。

实际结果:加载了你用鼠标选择的地图。


虽然游戏加载了一个地图,但是这不是测试员选择的地图,这就是一个bug,虽然不是一个精细的bug。


大部分时间里,缺陷是明显地。


4.点击“下一步”继续。


预期结果:继续游戏

实际结果:游戏锁定,你必须重新启动。


别为这些明显的事浪费时间。


要避免的事情


为了项目组成员间能清晰、有效地交流与合作,请努力避免两个编写bug报告时常犯的毛病:幽默和行话。尽管幽默在高压力的情况下受欢迎,但是在bug数据库中却并不受欢迎,且永远不受欢迎。有太多的机会产生误解和混乱。在危机时刻,是很容易发火,且神经紧张的。缺陷数据库可能已经成了争论的一个焦点。不要试图用幽默(即使你认为你的笑话引人发笑)而使问题变得更糟。


要在如此专业化形式的技术写作中避免行话,似乎可能违反直觉,但是这样做是明智的。虽然有些行话无法避免,并且每个开发团队很快就会发展出专用于他们正在工作的项目的自己的俚语,但是测试员应该避免使用(或错误使用)太多模糊的技术性术语。记住你的读者范围是从程序员到财经主管,所以请尽可能使用易懂的语言。


8.4小结 


虽然一个构造接一个构造去测试显得重复,但是每个新构造因其自身的成功(已修正的bug和已通过的测试)和不足(新的bug和未能通过的测试)提供了令人兴奋的新挑战。用结构性的方式来测试每个构造的目的,是减少浪费和从游戏团队中得到更多有用的东西。每一次,你都会得到用于重新规划测试执行策略和更新或改善你的测试套件的新构造的数据。为此,你准备了测试环境,执行了冒烟测试,来确定构造运行得足够好,从而能够配置到整个测试团队中去。一旦测试团队开始了,你最优先的事情通常是做回归测试,以便于验证最近的bug修正。之后,为了找到新bug和检查没有再次出现的旧bug,.你执行了许多类型的测试。做了许多适当的调查之后,新缺陷应该用一种清楚、简明和专业的方式去报告。一旦你完成这一旅程,你的奖励就是有机会将其重做一次。


8.5 习题


1.简单描述在详细描述bug的过程中,期望结果和实际结果间的差异。

2.回归测试的目的是什么?

3.简要描述配置准备的步骤。

4.什么是“推倒列表”?

5.判断对错:黑盒测试指的是检查实际的游戏代码。

6.判断对错:缺陷报告的简略描述应该包括尽可能多的信息。

7.判断对错:白盒测试描述测试机制。

8.判断对错:版本控制应该只能被应用于开发商的代码。

9.判断对错:bug.上的一个“验证修正”状态表示,它至少保留在另一个测试周期中。

10.判断对错:报告bug时,测试员应该编写尽可能多的步骤,从而确定该bug重现。

11.在紧靠床的一个桌子上有一个按键式电话。写好一步步的使用说明,告诉大家怎样使用这个电话拨打下面的号码:555-1234。假设阅读使用说明书的人以前从未见过或用过电话。


相关内容

文章评论

表情

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