说三道四技术文摘-感悟人生的经典句子
说三道四 > 文档快照

Bug报告:小角色,大用处!

HTML文档下载 WORD文档下载 PDF文档下载
软件测试是向开发者反馈软件存在的问题,一般以bug报告的形式进行。开发人员希望从bug报告那里收到错误信息的明确定位,而不是诸如“软件不好用”这样的无用信息。测试人员的工作是尽量的向技术支持方向靠拢。

本文作者Chris Kenst是一位专业的bug报告编写人员,曾参加Bug Advocacy Class的相关培训。在这片文章里,他为我们分析了bug报告到底有哪些作用,能带来哪些影响,在软件开发团队里又有着怎样的重要地位等等。(下面是编译内容)

为何要编写bug报告?

编写Bug报告的目的是为了让开发人员看到程序的错误,当然测试员也可以亲自给开发人员示范,当面交流,也可以在bug报告中给出导致程序出错的、详尽的操作步骤的描述。交流过程中尽量使用bug管理工具提出,这样做回归测试的时候,就能够有迹可循有据可依,同时也能够规范bug管理的过程。

对于软件测试人员来说,bug报告是我们能看的到的最明显的工作成果之一——是对系统调查的有形资产。测试人员的bug报告的质量好坏将直接影响到阅读报告的人如何理解这些bug,反之亦然,也将关乎到测试人员在程序员环境里的可信度和影响力。另外,bug报告在开发团队和测试团队之间起到一个重要的交流媒介的作用,因此,接下来将要强调的是如何理解bug报告和如何提高书写bug报告的技巧。

书写bug报告看上去很简单,像程序员、测试人员、内部和外部客户、分析师,他们并没有写过多少bug报告。不是和代码测试相关的人员就可以写这个报告的:某些东西很容易做,但并不意味着能把它们做好。

如何编写bug报告?

编写bug报告的重点是什么呢?找到bug,解决问题!作家Cem Kaner称之为Bug Advocacy,我们所倡导的方法是修复。程序员根本没有时间来阅读一个毫无意义的bug报告。如果出现的bug是相当明显的,程序员不用太多的信息就能将它修复,也就更谈不上什么bug报告了。我们所倡导的bug或问题是在某种程度上我们理解是重要的,但别人可能不容易理解的。

如何来修复那些被提倡的bug呢?所编写的bug报告要清楚地描述问题细节,用一个严酷但诚实的方式来反映问题,这样相关负责人员就能意识到风险所在并想方设法修复bug。仅仅复制问题可能并不足够,还要通过影响程序员的决定来引导他们修复这些bug,所以编写出好的bug报告起着重要作用。

为了帮助更好的理解bug报告里的那些细节部分,可以使用启发式的RIMGEA方法:

R—Replicate it。(复制)在编写bug报告的时候,必须要包含足够的能够解决bug的信息:必备的步骤和条件,将这个bug复制到另一台设备上。建议使用至少两台不一样的设备——一台主动力计算机和一台从动力约束计算机。其实,这些步骤在虚拟环境里同样可以施行。

I—Isolate it。(孤立)把问题复制之后,需要通过消除一些变量来确定复制问题所需的最简单的步骤或必要条件。同时,也要确保每个报告里只写一个问题,更要避免“一个bug修复了而其他bug仍然悬而未解”这样的情况出现。例如:在导入一个文件之后OpenOffice Impress挂掉了,但是复制品有25个步骤那么长,于是测试之后消除了一些变量,复制品只有6个步骤了。

M—Maximize it。(最大化)最大化的意思是做一些跟踪测试来观察除了刚开始在报告里提到的问题之外,是不是还有更严重的问题存在。跟踪测试包括改变方式、改变环境、改变输入值,甚至是改变系统配置。问题的严重性越大就越有可能说服程序员来修复这些问题。例如:我们无法将老的PowerPoint文件导入OO Impress,但是APP又不做出任何响应。经过一些跟踪测试之后,发现如果过量使用老的PowerPoint文件就会导致Impress死机。 

虽然最大化一个bug的过程比较有意思,但是在写bug报告的时候很费时。这其中就涉及到较为详细的四类变量:方法变量、环境变量、数据变量和系统配置变量。Markus Gartner的帖子里对这些变量做了详细的讲述。

G—Generalize it。(总结)对bug进行总结意味着我们可以了解这个问题所影响的人群范围是不是如之前所预料的那样大小。如果这只是一个角落案例,那么就在非极端环境下把这个问题展示出来。还是拿OO Impress为例,在改变输入值之后,不管输入什么类型的文件,只要是过量的,OO Impress都会死机。现在看起来,貌似不仅仅是老版本的PowerPoint用户遇到了麻烦。

E—Externalize it。(具体化)将对bug报告的注意力从程序上的问题转向相关联系人,这些人能够真实描述bug问题是如何对他们造成影响的。OO Impress因为过量导入文件而死机,与此同时也会阻止所有的用户导入适当的APP文件。还有可能阻止新的用户下载或安装APP,甚至是关闭现有依赖于兼容性的用户。

A—And say it clearly and dispassionately。(清晰冷静的表达)编写bug报告要确保别人能够理解报告所要表达的中心意思,报告的中心基调要保持中立,不冒犯阅读报告的任何一方(因为bug有可能是开发者导致的)。

如何成为一个Bug Advocate?

我们希望通过影响程序员、管理者和其它相关人员的决定来修复bug。只有清晰的bug报告才能达到这一目的,但要注意,还有一些同样重要的事情也可以影响我们成为Bug Advocates(并影响我们写这些报告的能力):

  • 软件错误的定义比较多(所以在bug报告里所说的错误要符合组织/团队的要求)。
  • 质量的定义也是比较多的。
  • 报告阅读者(开发者、测试人员、顾客)可能都带有在问题理解上的偏见。尽量减少他们之间的偏见,以解决问题为最终目的。
  • 要将无法解决bug的种种原因牢记于心:

  1. 参与者时间约束。
  2. 修复bug的成本过高。
  3. 在修复成本和添加一个顾客喜欢的功能之间进行权衡。
  4. 在读者眼里(管理者/程序员),bug编写者的可信度比较低。
  5. Bug问题只是一个角落问题,不可能影响所有的用户。

Bug Advocacy的价值

对于bug报告编写者来说,Bug Advocacy的价值真的很简单:

  • 丰富经验,写出更清楚更高效的bug报告。
  • 根据自身经验来评估别人的bug报告,并给出建设性的反馈。
  • 更好的理解bug报告所使用的交流媒介里所涉及到的细节/组成元素。
  • 在一个开源项目上贡献点时间和精力,回馈技术社区。
  • 在修复bug与否之间做出更好的权衡结果。

对于团队/组织来说,Bug Advocacy的价值在于贡献:

  • 更好的编写、评估和理解bug报告。
  • 增加深入探究、评估和改善bug报告的渴求欲。
  • 提升bug报告者的可信度,减少相互之间的偏见。
  • 更好的理解组织的需求。

下面引用Bug Advocacy课上Cem Kaner的话来作结束语:

最好的测试员不是发现了所有的bug或是让程序员难堪的人,最好的测试员是那个真正能够修复bug的人。                                                                                                        (编译/薛梁 校审/付江)

原文:MyTechFetish

备案号:鲁ICP备13029499号-2 说三道四 www.s3d4.cn 说三道四技术文摘