状态：提交缺陷报告到任何缺陷跟踪管理系统的时候，缺陷状态的默认值为“新建”，之后会经过各种不同阶段，如“已修复”、“已确认”、“重新打开”、“不修复”等等。

　　指派给：如果你知道问题产生的模块是由哪个开发人员负责的话，你可以直接填上该开发同事的电邮地址。如果不知道的话，就不填，把这个问题交给该模块的负责人或者经理，他们会分派给相应的开发人员的，也可以把问题抄送给经理。

　　URL：出现问题的页面链接

　　摘要：60个字或以下的简明摘要，要确保你的摘要能够反映出是在什么地方出现的什么问题。

　　描述：问题的详细描述，需要包括以下几方面：

　　● 重现步骤：清晰地描述重现问题的步骤

　　● 期望结果：基于上述步骤，系统应该出现什么样的结果

　　● 实际结果：基于上述步骤，系统实际出现了怎样的结果，也就是问题所在

　　这些就是缺陷报告的重要内容，你也可以在报告中再增加“报告类型”这一栏，用来描述缺陷的类型。

　　典型的报告类型有：

　　1）编码错误

　　2）设计错误

　　3）新的建议

　　4）文档问题

　　5）硬件问题

　　写一份好的缺陷报告的一些额外提示：

　　1）及时报告问题

　　一旦在测试中发现任何问题，马上写出错误报告。不要等着测试结束后再写详细的错误报告。这样做，才能保证你的报告是正确的，描述的问题可重现。你写报告的时间越晚，你遗忘其中步骤的可能性就越大，最糟糕的是你甚至可能遗忘这个问题。

　　2）编写报告之前，重现问题三次

　　你提交的问题必须是可以重现的，要确保你描述的步骤能够正确的重现而不会产生歧义。如果你发现该问题不是每次都出现的话，也可以把问题出现的周期写到报告里面。

　　3）在类似模块中，测试是否存在同样的问题

　　有时候，开发者会把同样的代码应用大到相类似的模块中。所以说，在相似的模块中，这类问题出现的概率会很高。甚至你可以尝试找到更多的问题。

　　4）写好问题摘要

　　问题摘要可以帮助开发人员快速的分析出问题的本质，质量差的报告会增加一些不必要的开发和测试时间。要通过问题摘要令到两者的沟通更为有效。记住，在缺陷报告库里查询问题的时候，问题摘要是当作查询条件来使用的。

　　5）提交之前，仔细检查

　　检查报告中的每一个句子、每一个词语、每一个步骤，看看是否有一些句子存在歧义而令人产生误解。要有一个清晰明了的缺陷报告，就应该避免出现一些含糊不清的句子或者词语。

　　6）切勿使用污言秽语

　　没错，你找到问题说明你很努力工作，这个值得赞扬，但是不能以此为傲，讽刺或者批评开发人员，或者是进行人身攻击。

　　结束语：

　　毫无疑问，你的缺陷报告应当是一份高质量的文档了。花些时间在提高写报告上，是有很大价值的。因为这是测试人员，开发人员和你的管理人员主要的交流重点。管理者应该使整个团队意识到，写出好的，高质量的测试报告是每个测试人员工作的首要责任。如果你的报告写的好，有价值，那么你不仅仅节约公司的资源，同时也会让测试与开发建立良好的关系。

版权声明：本文由会员ilove51首发于51Testing软件测试论坛。

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。