软件测试中如何编写一个更好的缺陷报告
我们是否经常看到开发人员针对我们归档的bug report要求提供更多的信息？我们是否经常需要在bug report归档后花更多的时间去研究那个问题？我们是否经常从开发人员那里听到在他们那边难以重现bug并且需要即刻提供“可重现的步骤”？广义上来说，我们与其花更多的时间在这些问题上还不如投资更多的时间来测试系统。问题出在bug report的质量上。这里介绍一些如何改进并达到完美bug report的建议。
Bug report的目的当我们发现一个缺陷时，我们需要把它告诉给开发人员。Bug report就是这种沟通的媒介物。Bug report的主要目的是让开发人员亲眼看到这个错误。如果你不能和他一起以在他面前制造出那个失败，那么就需要给他们足够多的指引以便他们能够自己制造出那个失败。Bug report就是解释在期望结果和实际结果之间的差距并且详细的说明如何重现那个场景。
什么是Bug报告，为什么我们要编写它？
Bug报告描述了所测试系统的失效模式，它也是软件测试工程的唯一可见产物。通过它与开发人员进行交流，并提高产品质量。
开发人员如果返回很多不可复现的Bug报告，那么我们用来编写这个Bug报告的时间就算是浪费了，同时也使开发人员和测试人员都感到沮丧，对产品质量的提高也没有任何的好处。
有多种原因可能产生一个不能复现的Bug报告，Bug不是连续出现的，测试和开发的环境不一致，对于什么是正确的行为有争论。但是很多不可复现的Bug报告则是由于不恰当的设想和编写的时候不注意造成的。
以下十条建议可以帮助我们编写一个好的Bug报告：
1.结构化：仔细的测试
2.复现：再测试一次
3.分离：用不同的环境或步骤来测试
4.概括：在其它相似的地方测试
5.比较：查看其它相似测试的结果
6.总结：把测试同客户联系起来
7.简化：去掉不必要的信息
8.去除歧义：用清楚的字眼来描述
9.中立:公正的描述问题
10.检查：再查看一遍。
要记住;写东西就是在创造，两个关于同一个问题的好的Bug报告在风格和内容上都是不一样，除了本质。
结构化：
结构化的测试是一个好的Bug报告的基础：
用有计划的，仔细的方法来测试，遵照之前写好的测试用例或者运行自动化测试用例，仔细的做好备注。
当我们所期望和所观察到的结果不一致的时候就产生了Bug报告，糟糕的测试也会导致糟糕的Bug报告。
好的软件测试更像是一个实验室里一个仔细设计的试验，而不是在闪电中随意行走或者更糟，毕竟，测试员是个工程师。
复现：
永远要把检查失效复现作为编写测试报告的一部分，一般来说，三次是比较好的。编写一个能复现这个失效的干脆的步骤。
当报告那些间断出现或者很难复现的失效时，要注明失效发生的几率，例如，尝试了3次，出现1次失效。
试着去找出那些不能复现的的Bug的步骤，事实上，很多时候是我们的步骤不正确或环境原因导致Bug不能复现。
分离：
改变某些参数可能会影响现象：
1.一次改变一个参数
2，这需要对所测试系统的理解和思考
3.可能不会马上见效
依据问题的严重程度来决定你要投入多少努力，同时要避免进入调试状态
好的分离工作可以显现出你的勤勉，同时给开发人员的调试活动一个好的开始。
概括：
寻找所测试系统中相关的失效，同样的失效是否存在于其它的模块或者其它的位置？同样的错误是否会导致更严重的后果？
同时要避免与不相关的问题相混淆，不同的Bug可能也会出现同样的症状。
通过概括可以减少重复的Bug报告，同时帮助更好的理解失效。
比较：
比较相似的测试的结果，有两层含义：一是在早期版本上运行的同样的测试，二是在当前版本上，相似的条件下，其它测试的情况。
考虑失效是否是一个回归问题？是否当前版本中的一个改变导致了在早期版本上不会出现的问题，这通常是在之前的版本上能通过在这版又失效的情况。
但这并不是都可行的，有时候在以前的版本上测试会遭受阻碍，重新安装又是不切实际的，有时候要测试的功能在之前的版本上并没有实现。
总结：
给每个报告弄一个标记线（Tag line),记住它的失效模式，同时想想可能给顾客造成什么影响，
比如说：保险杠贴纸（在美国开车，你很可能到处都会看到保险杠贴纸。上面的讯息可能是政治性的，宗教性的，时事导向的，或者是纯幽默性的。有些印刷公司可以让顾客自行设计贴纸上的标语。）
但是它不像看起来那么简单，测试人员需要时间来想这件事，好的总结可以起到以下的作用：可以得到管理阶层的重视，给Bug报告取一个好的名字，同时也有助于设置Bug的优先级别。
简化：
去掉那些不相干的步骤和文字，写完之后重新再仔细地读一遍，去掉那些看起来神秘或者啰嗦的字眼，考虑一下是否还存在无关的动作或者细节？每个人的时间都很有限，去掉那些无关的啰嗦，但是也不要去掉紧要的部分。
去除歧义：
去掉那些含糊的，误导人和主观的字眼或者描述，确保报告不会让人误解，去除歧义的目标是对于事实有清楚的，无可争议的陈述来引导开发人员。
中立：
温和的发表坏消息，在措辞和所包含的言外之意都要公正，避免攻击开发人员，批评低级错误或者任何的幽默或者讽刺，使Bug报告仅限于陈述事实，你可能不会想到以后谁将会阅读你的Bug报告。
检查：
每个测试人员都应该提交Bug报告给一个或者更多的同事去检查。而负责检查的同时则应该提出一些建议来提高Bug报告的质量，问一些使报告可以更清晰的问题，甚至在适当的时候挑战Bug成灾。
测试组应该在给定的有限的时间里提交尽可能好的Bug报告。
文章来源于领测软件测试网 https://www.ltesting.net/