对偶尔出现的缺陷的处理

    说这个话题之前，先假设有对缺陷评审的相对完善的机制，缺陷能够被准确的评估。再来说缺陷对处理问题。决定一个缺陷被如何处理，我想主要有两个方面的考虑，一是这个缺陷带来的系统风险的大小，另一个是对这个缺陷的修复成本的高低。在同一坐标轴上，这二者构成了四个象限区，如下图：

 

    在第四象限，带来的风险越大并且修复成本越低的缺陷最能够引起重视，通常会被最及时处理；相反，在第二象限，带来的风险越小但修复成本越高的缺陷，一般很难被快速处理，我们的情况是这类问题放在最低优先级处理。第三象限的缺陷则较第二象限优先处理。最棘手的是第一象限的问题，对于这类问题我们会通过投入人力或时间来解决。
    最后来说偶尔出现缺陷的问题。一般来说，缺陷若出现过一次，则总够通过某些步骤或构造特定测试环境使其再重现出来。因此测试人员要尽可能的保证所提交的缺陷能够被重现出来。为了避免缺陷“偶尔”出现，测试人员在测试过程需要保持清晰的思路，测试执行的过程要可重现（按照测试用例的描述执行），测试环境也要能够重新构造（包括服务器端环境和客户端环境，对系统运行的环境要有记录）。对于不是根据测试用例发现的缺陷，提交缺陷时还需一并描述该缺陷出现的环境及上下文条件。在这样的情况下，若仍发现了偶尔出现的缺陷，则可以按照前面提到的方法对缺陷进行分析，评估该缺陷所属象限，并据此判断是否需要对该缺陷进行持续跟踪。
    另外，遇到这类缺陷的时候也有必要与开发人员做充分的沟通，与开发人员一起分析缺陷可能产生的条件或原因。
    当然了，一定不能有侥幸心理，无论是对于开发人员还是测试人员，都是这样。偶尔出现的缺陷也一定要记录下来。我曾经遇到过测试人员偷懒或者是幸存侥幸心理不提交偶尔出现的缺陷的情况（因为重现困难，怕在开发人员面前出丑或是怕麻烦）。