最近经常看到开发人员针对我们归档的bug report要求提供更多的信息？经常从开发人员那里听到在他们那边难以重现bug并且需要即刻提供“可重现的步骤”？我试着考虑了下，难道问题出在bug report的质量上？当然bug report的编写也很重要哒。

     当我确信已经发现一个bug的时候于是就开始起草bug report，偶想最好及时上报，不要在测试即将结束或每天结束了才报告。那样，可能会遗忘掉一些复现的步骤。更糟的是，可能会忘掉那个bug。一旦真的遗忘咯，那后果。。。

Bug report的主要目的是让开发人员亲眼看到这个Error。如果你不能和他一起在他面前制造出这个Error，那么就需要给他们足够多的指引以便他们能够自己制造出那个Error。Bug report就是解释在期望结果和实际结果之间的差距并且详细的说明如何重现那个场景。
尽管不同的软件测试项目对于缺陷报告的具体组成部分不尽相同，但是偶想基本组织结构都是大同小异，89不离10，相通哒。一个完整的软件缺陷报告通常由下列几部分组成：

• 缺陷的标题；
• 缺陷的基本信息；
  • 测试的软件和硬件环境/版本号；
  • 缺陷出现的模块；
  • 缺陷出现的概率
  • 缺陷的严重程度；
  • 缺陷的处理优先级
• 复现缺陷的操作步骤；
• 缺陷的实际结果描述；
• 期望的正确结果描述；
• 注释文字和截取的缺陷图像/抓获的Trace信息。

   下面就几个注意点稍稍写一下子

标题Title:

title是bug Report中非常重要的一部分，它要求简单明了地对Error作一个整体的描述，让不知道这个Error的人看了之后能够很清楚地知道这是个怎样的Error。记得曾经有人提过“3W1H”的概念。也就是说，标题里面应该包括What is the error, When will the error appear, Where may the error appear and How to make the error appear.  

 

严重等级Severity

在设置bug report的严重程序之前应该全面的分析缺陷的影响程序。如果你认为你的bug具有很高的优先级应该被修复，在bug report中证明这点，应该在bug report的描述部分指出这个理由。Severity用来描述Error的严重程度，一般分为4等级，即：critical（A）、major（B）、normal（C）、enhancement（D）。偶测试手机软件哒，一般来说是指影响手机系统工作的Error即为A；影响用户操作的或者某些功能实现的Error即为B；微小的、不影响手机功能正常使用的Error即为C；而D一般是指一些小建议。

 

复现步骤（Reproducible Steps）

描述Error是否可再现，如果每次操作都能出现，就是可再现的。如果只是某一次操作才会出现这个Error，则是不可再现的。如果是不可再现错误，要记录一共出现过多少次，是在英文界面还是在中文界面。每个Error都有发生的前提条件和操作步骤。严格的说，每个Error都是可重现的。但是，发现这个Error的人可能没有能够找到这个error的完整的前提条件或者完整的操作步骤。所以，现实中就有了很多不可重现的Error。对于一个手机而言，硬件，软件，语言包和SIM卡都是其重要的组成部分。所以，在一个手机中用某种SIM卡在某种语言的UI上发现了某个Error，有可能在同样的手机，同样的SIM卡，不同的语言的UI上就没有这个Error;也有可能在同样得手机上用不同的SIM卡也会没有这个Error；同样，在不同的手机上也有可能发现不了这个Error。总之一句话，是否可重现，要考虑手机硬件、软件版本、SIM卡类型、UI类型等等相关的影响，不能简单的说某个Error可重现，有的时候要加上注释。

 

复现步骤即如何使别人能够很容易的复现该缺陷的完整步骤。对发生错误的描述，用简明易懂的话详细地把这个Error描述清楚。注意几个要点：“详细”、“简明”、“清晰”，让别人能够轻松的理解并完成操作这个可以分成几个步骤来写，如步骤1、步骤2、步骤3等。例如：

1. Menu --> Call register --> enter one of full window choice items;

2. Receive a call;　

3. Reject it or remote end terminats the call.

不要在bug report中夸大缺陷。同样，也不要太轻描淡写了。不管bug是多么的令人讨厌，别忘了是bug令人讨厌，而不是开发人员。永远不要冒犯开发人员的努力。使用委婉些的说法。如：“混乱的UI”可以被温和些改为“不正确的UI”。这样开发人员的努力将会得到尊重。

 

在编写bug report的时候记住你的目标读者。他们可能是开发人员，其他的测试人员，经理，或者在一些情况下，甚至是客户。Bug report应该可以被所有的人理解。“可重现的步骤”的流程应该是合乎逻辑的。

 

综合上所述，良好的复现步骤应该包含本质的信息，偶感觉应该按照下列方式书写：

1.提供测试的预备步骤和信息；如，如果默认项或预设、调试版本或发布版本等存在问题，请指明使用的操作系统和应用程序的环境变量；

2.复现路径。如果有多种方法触发该缺陷，请在步骤中包含这些方法。同样地，如果某些路径不触发该缺陷，也要包含这些路径。 简单地一步一步地引导复现该缺陷； 每一个步骤尽量只记录一个操作；每一个步骤前使用数字对步骤编号； 复现的操作步骤要完整，准确，简短； 没有缺漏任何操作步骤； 每个步骤都是准确无误的； 没有任何多余的步骤； 将常见步骤合并为较少步骤。

另外，如果你的bug是随机出现的，只需在你的bug report中说一下就可以了。但是不要忘记归档它。你总是能够在你发现它们之后的任何时间里增加准确的步骤。这也将在其他人提交这个问题时解救你，特别是当那个问题比较严重时。

注释（Notes）

注释应该包括复现步骤中可能引起混乱的补充信息，是对操作步骤的进一步描述，这些补充信息是复现缺陷或隔离缺陷的更详细的内容。

 

实际结果（Actual result）

实际结果是执行复现步骤后软件的现象和产生的行为。

实际结果的描述很像缺陷的标题，是标题信息的再次强调，要列出具体的表现行为，而不是简单的指出“不正确”或“不起作用”。

期望结果（Expected result）

期望结果的描述应该与实际结果的描述方式相同。通常需要列出期望结果的应该是什么，并且给出期望结果的原因，可能是引用的规格说明书、前一版本的表现行为、客户一般需求、排除杂乱信息的需要等等。

书写清晰、完整的缺陷报告是对保证缺陷正确处理的最佳手段。它也减少了工程师以及其它质量保证人员的后续工作。
为了书写更优良的缺陷报告，需要遵守“5C”准则：

• Correct（准确）：每个组成部分的描述准确，不会引起误解；
• Clear（清晰）：每个组成部分的描述清晰，易于理解；
• Concise（简洁）：只包含必不可少的信息，不包括任何多余的内容；
• Complete（完整）：包含复现该缺陷的完整步骤和其他本质信息；
• Consistent（一致）：按照一致的格式书写全部缺陷报告。

缺陷报告的写作注意事项

提高缺陷报告的写作水平是不断积累经验，循序渐进的过程。在正式提交缺陷报告前，请对缺陷报告的内容和格式进行自我检查，避免很多不必要的错误。花一些时间去诊断你正在报告的缺陷。想想可能存在的原因。可能到最后你会发现更多的缺陷。在你的bug report中说说你的发现。开发人员将不仅仅对你使他们的工作变得轻松而感到高兴，同时也是自己的一个很好的提升。

1 自我检查和提问

• 缺陷报告已经向读者包含完整、准确、必要的信息了吗？
• 一个缺陷报告中是否之报告了一种缺陷？
• 读者是否能容易的搜索该缺陷？
• 步骤是否可以完全复现而且表达清楚吗？
• 是否包含了复现该缺陷需要的环境变量或测试所用的数据文件？
• 缺陷的标题是按照原因与结果的方式书写的吗？
• 实际结果和期望结果是否描述不够清楚而容易引起歧义吗？

2 避免常见的错误

• 使用“I（我）”、“You（你）”等人称代词。可以直接使用动词或必要时使用“User（用户）”代替；
• 使用情绪化的语言和强调符号，例如黑体、全部字母大写、斜体、感叹号、问号等。只要客观地反映出缺陷的现象和完整信息即可，不要对软件的质量优劣做任何主观性强烈的批评、嘲讽；
• 使用诸如“Seems（似乎）”、“Appears to be（看上去可能）” 等含义模糊的词汇，而需要报告确定的缺陷结果；
• 包含认为比较幽默的内容，因为不同读者的文化和观念不同，很多幽默内容在别人看来，往往难以准确理解，甚至可能引起误解。只需客观地描述缺陷的信息即可；
• 将不确定的测试问题（Issues）放在缺陷管理数据库中。如果对测试软件的某个现象不确定是否是软件缺陷，可以通过电子邮件或口头交流，确认是缺陷后再报告到数据库中。避免查询和统计结果的不准确性。

提供准确、完整、简洁、一致的缺陷报告是体现软件测试的专业性、高质量的主要评价指标。遗憾的是，一些缺陷报告经常包含过少或过多信息，而且组织混乱，难以理解。由此导致缺陷被退回，从而延误及时修正，最坏的情况是由于没有清楚地说明缺陷的影响，开发人员忽略了这些缺陷，使这些缺陷随软件版本一起发布出去。由此可见，软件缺陷报告的编写的重要性，希望以后的日子里偶们对bug report做好，精益求精，偶们一起努力吧。。。