ISTQB AL-TM连载系列16：如何处理难以重现的缺陷

在测试执行过程中，经常会碰到一些不可重现或者很难重现的缺陷，特别是在进行系统的非功能性测试的时候，例如：稳定性测试、压力测试、满配置测试、兼容性测试等。在非功能性测试过程中发现的缺陷往往是严重程度比较高的，例如：系统不稳定、系统在不可预测的时候重启等。假如软件产品交付给用户之后，在用户现场或者系统运行过程中出现由于这样的缺陷而导致的失效，那么将会大大影响用户对产品的信心。

虽然有的组织和项目可能不统计无法重现或很难重现的缺陷，甚至忽视难以重现的缺陷。但是笔者认为，针对难以重现的缺陷，可以采取以下措施改进测试的效率和有效性：

尽量获取系统的打印信息和DEBUG信息；
测试人员应该报告不可重现的缺陷；
在产品操作指南（使用说明）中明确告知客户；
缺陷报告中明确该缺陷能够重现的可能性；

1）尽量获取系统的打印信息和DEBUG信息

尽管测试人员在测试过程中经常会碰到一些难以重现的缺陷，但是，系统出现异常行为的时候，通常总是会存在一些蛛丝马迹的。这就需要测试人员需要有足够的耐心和细心。同时，测试人员在测试过程中，应该养成有些良好的习惯，例如：打开系统的DEBUG端口，不断捕获系统的打印信息，特别是信息中提示错误和告警的信息，从而帮助开发人员跟踪和定位缺陷发生的原因，从而有利于开发人员解决这种类型的缺陷。

例如：在测试过程中，测试人员经常会碰到系统重启的问题。对于这样的问题，我们可以从下面几个方面对该问题进行分析：

仔细分析DEBUG端口中打印的错误和告警信息，例如：信息是系统级别的，还是模块级别的？系统什么情况下会出现这样的信息？
分析系统在什么情况下会出现重启，例如：数据的溢出、野指针、堆栈溢出。通过分析原因，可以更好的分析导致缺陷的根本原因。

2）测试人员应该报告不可重现的缺陷

即使是不可重现的缺陷，笔者认为，测试人员也应该报告这样的缺陷。假如组织内要求测试人员报告不可重现的要求，可以推动测试人员对这样的缺陷进行仔细的研究和分析；报告不可重现的缺陷可以形成项目的不可重现的缺陷数据库，定期浏览这些缺陷，并进行集中的分析，可能会在不同的缺陷描述中发现一些共同的或者可能有联系的信息，有助于问题的解决。

另外，报告不可重现的缺陷，也有助于测试人员和开发人员对这类问题和系统表现进行跟踪。

3）在产品操作指南（使用说明）中明确告知客户

对于通过测试人员和开发人员共同努力，还是无法进行重现的缺陷，测试人员不仅要报告缺陷，如果该缺陷可能对用户的使用有较大的影响，测试人员还应该在测试报告中描述这样的缺陷，告诉用户缺陷的表现，可能导致的问题，以及可能的补救方案。

通过在用户操作指南（用户手册）中明确告知系统存在的一些不可重现的问题，不仅可以让客户了解产品中可能存在的问题，提前有一定的心理预期；同时在他们碰到问题的时候，也可以根据我们提供的一些补救方案，客户可以继续使用产品。

4）缺陷报告中明确该缺陷能够重现的可能性

最后，测试人员在报告不可重现的缺陷时，应该在缺陷报告中明确提示该缺陷不可重现或者难以重现，避免在进度压力太大的情况下，开发人员将精力过多地放在这种类型的缺陷修复上。

[文章来源]：专注于测试能力改进