编写优秀缺陷报告（Bug report）的艺术
Bug report的核心是对错误的描述，而优秀的bug report对反映测试小组真实的和可理解的工作质量同测试本身一样都是非常重要的。那么什么样的缺陷报告才是优秀的缺陷报告呢？这里我引用一位测试界的大师总结的十大特性，并加上自己对于目前很多缺陷报告存在的问题的分析。希望可以给相关的测试工程师编写缺陷报告时进行参考：组织Structure：测试人员应该采用深思熟虑的，小心谨慎的方法执行测试，并且做详尽的记录。这样可以促使他们对测试下的系统有很好的认识。当错误发生的时候，一个有组织的测试人员能够知道最早出现问题的地方。（目前存在的主要问题：在编写报告时逻辑不够清晰，开发人员拿着缺陷报告还需要通过打电话跟测试人员交流才能重现问题，甚至需要让测试人员当着开发人员来重现。往往一个问题需要交流上好几次才能解决。）
重现Reproduce：测试人员在编写bug report之前必须在检查问题是否可重现。如果错误不可再重现，仍然应该写下来，但是必须说明问题的偶然性。一个好的处理原则就是在编写bug report之前反复尝试3次。（目前存在的主要问题：很多时候测试人员因为时间不足（或者这个只是借口）根本就不按照测试用例来执行（测试用例这个时候只是一件例行的输出件），所以发现问题的过程有时很随机，以致在填写缺陷报告时也没有一个规格化的顺序，可重现性比较差。）隔离Isolate：在尝试编写bug report之前，必须试着隔离错误。可以采用改变一些变量的方法，如系统的配置，它可能可以改变错误的症状。这些信息可以为开发人员着手调试提供思路（目前存在的主要问题：由于有些问题在很大程度处决于周边的操作，比如多个测试人员同时使用同一套测试环境时，不可避免的存在相互影响，这个时候如果需要确保问题能得到合理的理解，需要测试人员把周边环境描述清楚，而实际上这点往往更容易被人忽视
归纳Generalize：在测试人员发现了一个已隔离的，可重现的问题后，应该对问题进行归纳。同一个问题是否出现在其他的模块或其他的地方？同一个故障是否有更加严重的问题？（目前存在的主要问题：很多人并不是不清楚某个问题可能在其他地方也可能出现，只是有时为了在统计Bug数量时有一个令人满意的数量，而故意把本来是一个或者一类问题的问题拆分成多个。）对比Compare：如果测试人员以前曾经验证过现在出错的测试用例，那么他就应该检查以前的测试结果以检查相同的条件是否通过以前的测试。如果是的话，那么这个问题就象是一个回归的错误。注意由于同一测试条件有可能出现在多个测试用例中，这个步骤就不仅仅只是检查一个测试用例在以前的多个结果。（目前存在的主要问题：很多测试人员对于回归测试的理解仅仅停留在上个版本的用例在回归版本的重复执行，而对于用例的大的预制条件考虑得不够充分。）总结Summarize：在bug report的第一行写上错误的总结是非常关键的。测试人员要花些时间思考已发现的错误对客户有何影响。这不仅仅要求测试人员编写的报告要能够吸引读者，使和管理层的沟通清晰，还要能够帮助设置错误修复的优先级别。（目前存在的主要问题：在写缺陷报告标题时，很多人只是简单描述下现象，都把现象作为标题，而原因并没有在标题上也提示出来，他总是认为开发人员或者客户不管怎么都会看完整个缺陷报告。）精简Condense：在bug report的初稿完成后，测试人员应该反复阅读它，集中剔除那些没有关系的步骤或词语。隐含的或模糊的说明和那些由于对没有任何关系的细节或者那些在重现错误过程中不需要的步骤而消磨报告欢迎程度的无穷唠叨都不是bug report的目标。（目前存在的主要问题：事实上报告要做到在精简和翔实之间找到一个平衡点，很多时候测试人员一般会认为越详细的报告越有助于开发人员去重现问题。）
消除歧义Disambiguate：测试人员在精简空话的同时或其之后随即应该再仔细检查报告是否有会产生误解的地方。测试人员应该尽量避免使用模糊的，会产生歧义的和主观的词语。目标是使用能够表述事实，清楚的，不会产生争执的词语。（目前存在的主要问题：测试人员在对一些不能必然重现的问题时，一般都会说这种情况在某些可能的情况下会发生。对自己不确定的问题很喜欢加上“可能发生”，“正常情况下会重现”等).
中立Neutralize：如文中所述，作为坏消息的传递人，和善地提交消息是一个挑战。如同所有的错误总结一样，独立的bug report在措辞方面应该保持公正。攻击开发人员，指责潜在的错误，企图诙谐或使用挖苦将引起开发人员的憎恶，并且使注意力从“提高产品质量”这个大的目标上转移开了。谨慎的测试人员只用Bug report来描述事实。（目前存在的主要问题：测试人员有时在对于连预测试都没有通过的遗留到正式测试时的问题会感到气氛，认为开发人员怎么一点都不负责，因此报告中会情不自禁的加上自己的感情色彩。）检查Review：一旦测试人员感觉bug report是他能够编写的最好版本，他应该将报告再给一个或多个同行进行检查。他的同事们也应该给出一些建议，为了澄清问题不断地提问，如果适当的话，甚至可以挑战“错误成灾”的结论。在允许的时间里，测试小组应该尽可能提交最好的bug report。（目前存在的主要问题：业界的测试人员很少会把自己的缺陷报告供其他人去评审和检查，除了测试组长可能会简单审核下问题以外。）
总结：缺陷报告是体现测试工程师价值和水平的东西，希望这十条建议对大家能有一定的帮助，同时大家也可以思考下，在填写缺陷报告的过程中，您是否也出现过同样的问题。
重现Reproduce：测试人员在编写bug report之前必须在检查问题是否可重现。如果错误不可再重现，仍然应该写下来，但是必须说明问题的偶然性。一个好的处理原则就是在编写bug report之前反复尝试3次。（目前存在的主要问题：很多时候测试人员因为时间不足（或者这个只是借口）根本就不按照测试用例来执行（测试用例这个时候只是一件例行的输出件），所以发现问题的过程有时很随机，以致在填写缺陷报告时也没有一个规格化的顺序，可重现性比较差。）隔离Isolate：在尝试编写bug report之前，必须试着隔离错误。可以采用改变一些变量的方法，如系统的配置，它可能可以改变错误的症状。这些信息可以为开发人员着手调试提供思路（目前存在的主要问题：由于有些问题在很大程度处决于周边的操作，比如多个测试人员同时使用同一套测试环境时，不可避免的存在相互影响，这个时候如果需要确保问题能得到合理的理解，需要测试人员把周边环境描述清楚，而实际上这点往往更容易被人忽视
归纳Generalize：在测试人员发现了一个已隔离的，可重现的问题后，应该对问题进行归纳。同一个问题是否出现在其他的模块或其他的地方？同一个故障是否有更加严重的问题？（目前存在的主要问题：很多人并不是不清楚某个问题可能在其他地方也可能出现，只是有时为了在统计Bug数量时有一个令人满意的数量，而故意把本来是一个或者一类问题的问题拆分成多个。）对比Compare：如果测试人员以前曾经验证过现在出错的测试用例，那么他就应该检查以前的测试结果以检查相同的条件是否通过以前的测试。如果是的话，那么这个问题就象是一个回归的错误。注意由于同一测试条件有可能出现在多个测试用例中，这个步骤就不仅仅只是检查一个测试用例在以前的多个结果。（目前存在的主要问题：很多测试人员对于回归测试的理解仅仅停留在上个版本的用例在回归版本的重复执行，而对于用例的大的预制条件考虑得不够充分。）总结Summarize：在bug report的第一行写上错误的总结是非常关键的。测试人员要花些时间思考已发现的错误对客户有何影响。这不仅仅要求测试人员编写的报告要能够吸引读者，使和管理层的沟通清晰，还要能够帮助设置错误修复的优先级别。（目前存在的主要问题：在写缺陷报告标题时，很多人只是简单描述下现象，都把现象作为标题，而原因并没有在标题上也提示出来，他总是认为开发人员或者客户不管怎么都会看完整个缺陷报告。）精简Condense：在bug report的初稿完成后，测试人员应该反复阅读它，集中剔除那些没有关系的步骤或词语。隐含的或模糊的说明和那些由于对没有任何关系的细节或者那些在重现错误过程中不需要的步骤而消磨报告欢迎程度的无穷唠叨都不是bug report的目标。（目前存在的主要问题：事实上报告要做到在精简和翔实之间找到一个平衡点，很多时候测试人员一般会认为越详细的报告越有助于开发人员去重现问题。）
消除歧义Disambiguate：测试人员在精简空话的同时或其之后随即应该再仔细检查报告是否有会产生误解的地方。测试人员应该尽量避免使用模糊的，会产生歧义的和主观的词语。目标是使用能够表述事实，清楚的，不会产生争执的词语。（目前存在的主要问题：测试人员在对一些不能必然重现的问题时，一般都会说这种情况在某些可能的情况下会发生。对自己不确定的问题很喜欢加上“可能发生”，“正常情况下会重现”等).
中立Neutralize：如文中所述，作为坏消息的传递人，和善地提交消息是一个挑战。如同所有的错误总结一样，独立的bug report在措辞方面应该保持公正。攻击开发人员，指责潜在的错误，企图诙谐或使用挖苦将引起开发人员的憎恶，并且使注意力从“提高产品质量”这个大的目标上转移开了。谨慎的测试人员只用Bug report来描述事实。（目前存在的主要问题：测试人员有时在对于连预测试都没有通过的遗留到正式测试时的问题会感到气氛，认为开发人员怎么一点都不负责，因此报告中会情不自禁的加上自己的感情色彩。）检查Review：一旦测试人员感觉bug report是他能够编写的最好版本，他应该将报告再给一个或多个同行进行检查。他的同事们也应该给出一些建议，为了澄清问题不断地提问，如果适当的话，甚至可以挑战“错误成灾”的结论。在允许的时间里，测试小组应该尽可能提交最好的bug report。（目前存在的主要问题：业界的测试人员很少会把自己的缺陷报告供其他人去评审和检查，除了测试组长可能会简单审核下问题以外。）
总结：缺陷报告是体现测试工程师价值和水平的东西，希望这十条建议对大家能有一定的帮助，同时大家也可以思考下，在填写缺陷报告的过程中，您是否也出现过同样的问题。
