测试工程师如何提供一份优秀的缺陷报告

        在测试工作中，有个问题是所有阶段的测试工程师都可能遇到的：提交的BUG被开发开发拒绝修复，据理力争容易产生矛盾。作为测试工程师，我们既不能强迫开发进行修复，也不能随意放任BUG上线，那么怎么做才能体现职业素养呢？

1、清楚地说明每一个缺陷对用户的危害。

第一，缺陷报告要重点说明该缺陷对用户价值的损害。许多软件项目都进度紧张、资源有限，项目团队修复一个严重的缺陷，可能需要考虑多个因素。例如：修复该缺陷可能需要2天，而实现一个用户建议的新功能也需要2天，是修复缺陷还是增加功能对用户更有价值？目前，软件即将发布，修复该缺陷会不会引入新的问题？为了修复该缺陷而推迟发布是否值得？这些问题的核心因素是该缺陷是否显著地降低了软件对用户的价值，以至于开发人员与测试人员愿意占用开发活动的时间、冒着引入更多缺陷的风险来修复它。如果缺陷报告没有写清楚缺陷的影响，有可能会错误地认为这是一个不重要的问题，并将它标记为“不予修复”。

2、提供尽可能多的技术信息，方便程序员调试

第二，缺陷报告应该提供尽可能多的信息，以便程序员修复缺陷。缺陷不被修复或没有被及时修复的常见原因是程序员没能重现该缺陷。对于难以重现的问题，测试人员应该收集并报告尽可能多的信息，例如有可能重现缺陷的操作步骤、屏幕截图等。软件测试是技术调查，缺陷报告作为调查结果，应该包含技术层面的信息，帮助程序员更快地修复问题。以web测试为例，我们不但需要提供操作步骤，还应该提供进行该操作时浏览器发送的关键请求，以及请求中所包含的参数，方面程序员重现问题。

3、尽早提交缺陷报告。

第三，缺陷越早被报告，越有可能被修复。当项目临近发布时，项目团队会对代码变更采取谨慎的态度，因为最后时刻的代码修改可能会引入一些新的缺陷，而短时间的测试不能发现这些缺陷。因此，缺陷评审会议常常因为风险较高而拒绝修复一些缺陷。这样的情况我遇到过多次，如果能早一些提交该缺陷，哪怕是早一个星期，它就能得到修复。这给我两个启示：一是要第一时间提交发现的缺陷，而不是统一提交（即：一个缺陷一个缺陷报告，而非整体提交）；二是在制定测试策略时，要以优先发现严重缺陷为目标（即：优先主流程，暂时忽略细枝末节。而并非根据模块一条条执行测试用例）。有时，软件的表现出乎我们的预料，但是并不能确定这一定是个缺陷。这说明测试人员对软件的设计和实现还有不了解的地方，我们应该将此疑惑视为一个学习的机会，通过阅读文档、咨询同事等方法来获得解答。然而，在测试时间紧张的情况下，深入调查是不适宜的。如果不能立即获得解答，应该提交缺陷报告，让产品经理或缺陷评审会议来回答。

4、报告发现的所有缺陷，即便有些缺陷难以重现。

第四，为了提供完整的信息，我们应当报告发现的所有问题。这并不意味着提交重复的信息。在提交缺陷报告之前，可以查询一下缺陷管理系统，了解被测功能有哪些活跃的缺陷。如果其他测试人员已经提交了这个缺陷，那么测试人员可以跳过报告，继续测试。我建议测试人员在查询相似缺陷上不必花费太多的时间，只要避免明显的重复提交即可，因为重复提交的开销远小于遗漏报告的代价。而且，程序员通常能够快速地链接根源相同的两份缺陷报告，将它们“并案”处理。

对于程序员来说，时间不充裕的情况下被告之需要修复BUG的心情是烦躁的。当看到GET不到重点的缺陷报告时会加重这种情绪，甚至会对测试人员的专业性提出质疑。因此作为测试人员，我们不但需要尽可能早的提交缺陷报告，还需要将问题尽可能清楚的描述出来。