如何记录一个Bug

当测试人员在执行测试用例的过程中发现Bug时，测试人员应该如何记录这个Bug？如何确保开发人员能理解自己所提交的Bug？本节将详细解答这些问题。

一个Bug所包括的内容

通常情况下，一个Bug应包括以下信息点

每个公司的不同项目对Bug应包括的信息点可能存在一些细小的差异，但大体思想是一致的，进入公司后按照公司的要求和模板书写便可。

Bug记录的正确范例

例1：某测试人员打开XYC邮箱的登录首页，输入正确的用户名和密码后成功登录到XYC邮箱内页，然后单击“写信”按钮进入写信页面，随后输入正确的邮件地址、正确的主题、正确的正文，然后单击“发送邮件”按钮，但之后页面没有任何反应，无法发送邮件。很明显，这就是一个Bug，那测试人员应如何记录这个Bug呢？

对于Bug的记录，需要注意以下3点。

（1）Bug的概要一定要清晰简洁。

（2）在Bug的具体描述中，测试的步骤和使用到的具体数据都要清楚地写出来；在Bug的具体描述中尽可能多地提供一些必要信息，如本例具体描述中的第6步。

（3）如果可以截图，一定要截图，因为这是最直接的证据，一般的操作系统都有截图软件。以上3点都是要提交给开发人员的关键信息，开发人员需要依据这些关键信息去定位Bug的原因。

例2：某测试人员打开XYC邮箱的登录页面，输入错误的用户名和密码，随后单击“登录”按钮，此时系统无法登录，但系统也没有给出任何提示。很明显，这也是一个Bug。那测试人员应如何记录这个Bug呢？

其中对于Bug的优先级，相信初级软件测试人员都可以正确判断，提醒大家一点：设置处理Bug的优先级的目的是告诉开发人员处理此Bug的优先级别，以便开发人员合理地安排Bug修复工作。

例3：某测试人员打开XYC邮箱的登录页面，输入正确的用户名和密码后成功登录邮箱，然后单击“写信”按钮进入写信页面，测试人员准备在收件人地址栏中输入一个邮箱通讯录中已存在的邮件地址，但当测试人员输入该邮件地址的第一个字符时，发现系统并没有自动联想出以该字符开头的所有邮件地址。

分析：如果该需求文档并没有要求收件人地址栏要具备自动联想功能，那么此问题，测试人员就可以当作建议性问题提出来。测试人员应该如何记录这个建议性的Bug呢？

描述Bug的发生过程并记录相关数据，这对一名初级测试人而言并不是一件很困难的事情。初级软件测试人员在记录一个Bug时，应尽可能多地提供一些详细的信息和截图。本书所列的Bug示例也许并不是最好的，初级软件测试人员入职后应多参考其他同事曾提交过的Bug示例单，并学习其中的优点。

总之，提交清晰的Bug示例单是初级软件测试人员十分重要的一项工作，如果Bug示例单中的内容缺少关键步骤和具体数据等重要信息，这不仅给开发人员修复Bug带来难度，还有可能会被直接退回给测试人员并要求重新书写Bug示例单。

求职问题

如何提交高质量的缺陷？

参考答案：

1. bug概要 简洁，清晰，描述缺陷的要点，能够描述清除是什么问题。

2. bug的具体描述，细节越详细越好，以及出错数据描述清楚。

3. 可以加上对应的截图和日志。

4. 所测试软件版本号以及测试环境，不同版本，不同环境可能会造成不同测试结果。

如果你发现了一个bug，但是这个bug之后再也无法重现，你会怎么办？

参考答案：

1. 尽可能的保留截图，以及对应的日志，保留好测试现场。没有重现问题可能是没有触发引起此bug的某个点，所以作为测试人员我会想尽一切办法让这个bug重现。

2. 如果实在无法重现，还是会提交bug给开发人员。如果有截图和日志，会一并提交。

3. 如果开发人员要求重现，那么测试人员就需要后期继续观察，如果最终还是无法重现，会将此问题提交给测试经理。由测试经理和开发人员商定解决办法。虽然现在不能重现，但是不代表不会在用户哪里重现。

如果开发人员不修改你发现的bug，原因是因为修改的成本比较高，这个bug只是影响用户体验而已，你会怎么办？

参考答案：

我觉得影响用户得设计不是好的设计，任何影响用户体验的问题都是大问题，这个产品就不是一款好产品。

如果每个问题都因为成本高就不去修改的话，是无法持续提升产品的质量。

我觉得只要是问题，无论大小，测试人员都应该要求开发人员去修改，这是对产品负责，也是对用户负责。