这不是一篇关于软件测试人员的工作评论方面的文章。最近参加了一个测试总结会，至少在两个项目汇报过程中发现，开发管理者感兴趣的一个度量指标是：你们发现了多少个bug？然后，当得到的回答是一个很高的数目或是一个很严重的缺陷（如：3个严重的bug！），就会得到热烈的鼓掌。
不过，我感觉这样做是不对的！我的第一反应是，好吧，让我换种说法……
“在我们的产品中，我们在设计和实现过程中出现了多少严重的缺陷？”“仅仅3个？”“太棒啦！（鼓掌）”
或者是：“哦，测试团队，你找出了多少个我们程序的致命错误？”“才3个？”，带着得意的笑容，“感谢测试团队（鼓掌）”
安息吧，bug！
这表明，询问“多少个bug？”是种错误的方法，像这样的事情，我一旦发现会严厉地批评。但后来我意识到，这个特有标准的诱惑也曾让我深受其害，不仅在我过去无知的岁月中，甚至更多的是现在。为什么呢？对“多少个bug”的有效性来说，这意味着什么呢？ 下面是我的一些观点。
三个阶段
软件开发的生命周期可以按多种不同的方式进行切分。在这里，按我的观点，我会把它描述成3个阶段（见上图）。
- 阶段1：设计、开发、单元测试
- 阶段2：功能测试、上线前的评估测试：性能测试、压力测试、使用场景模拟
- 阶段3：线上监控、线上测试、客户反馈
上面列出来的项目是我们在每个阶段参与的以质量为中心的活动。
当我们询问发现了多少bug的时候，我们是针对第二阶段。所以问这个问题本身不是错误的，错误在于我们忽略了第一和第三阶段质量的影响和贡献。
阶段1的质量
在这篇博客开头，我开了一些玩笑，我现在想说的是第二阶段的高bug数意味着第一阶段质量下降。当开发总是主导设计，一个可靠的质量将会来自测试（系统的可用性和可测性）和项目管理（客户至上）的贡献。开发完成的质量不仅仅依赖于好的开发经验，当测试驱动开发（TDD）被用上的时候，还跟单元测试紧密相关。除此之外，单元测试也能让我们对“所得是否所需”有个最基本的了解。
阶段1的质量指标：
- 开发和测试、PM一起展开设计评审（双重检查）；
- 需要结对review的代码的百分比。我的观点是--100%。这不仅是为了指出代码中的错误，更是一种重要的方式，能让高级开发人员指导更多初级开发人员使用更好的开发经验，比如采用设计模式和代码重用；
- 单元测试代码覆盖率。咦，我有提到过？一些人可能会想象这是一个有争议性的论断。但就像bug的数目没有尽头，而是一个未知数一样，代码覆盖率也是；
- 代码覆盖率缺口分析：那些没有覆盖的代码，我们是否遗漏了什么？
- 静态代码检查；
阶段2的质量
我想阐明的一个主要观点是：当许多软件专业人员想到软件质量的时候，他们就会想到这个阶段。这种观念的错误可以用一句谚语来概括：“质量不是测试可以测出来的”（如果有人知道这句谚语是谁说的，请告诉我下）。
这只是整个过程的一个阶段。有很多阶段1的质量评估方法在这有对应的部分：
- 测试计划是否被开发和PM review？
- 测试代码结对review的百分比；
- 集成测试代码的覆盖率（和往常同样的说明）；
然后是这个阶段特有的部分：
- 有记录的测试结果：这个对性能测试和压力测试尤为重要，因为它提供了我们所知的能在生产中接受的基准指标。
- 所发现的bug数目和严重程度。重点就在这了，因为它是一个有效的质量/风险指示器。但它不能放在真空中，它必须和第1、第3阶段的结果在一起才能说明问题。
- 难道发现大量的、很严重的bug，就意味着超级有效的第二阶段会把这个产品所有的风险排除？或者意味着阶段1质量非常糟糕时，我们可以期望更多的灾难折磨我们的客户？
- 难道一个很少的bug数意味着我们阶段2的工具是在浪费时间？或者意味着阶段1非常给力然后带来了高质量的代码？
阶段3的质量
我之前讲过线上测试（TiP），它是一个有效的针对软件产品的测试方法。这种方法的接受程度（不是方法本身）还有点新。然而线上监控就不新鲜了。亚马逊就是一个很好的例子，快速开发和良好支撑的监控工具，加上其它工具使得亚马逊能对产品发布作出快速响应（也就是补丁），这已经成为亚马逊各种服务的质量保证制度的一部分。你也许会问，即使你能找到线上缺陷并快速修复，难道就允许将这些缺陷带到生产中？“质量”，是的，你只要问问亚马逊的用户他们是否遇到过问题，或者看看亚马逊的用户满意分数就明白了。
既然我们承认产品有一个合理的质量阶段，那为什么不在第2阶段把所有的问题找出来，而不用管第3阶段呢？问题的答案是成本。如果我们尝试用第二阶段的大规模预先测试找到所有的问题，那我们就会因为不断增加的成本而得到越来越少的回报。在前面两个阶段的基础上，用上第3阶段是一个合理的、划算的方式，能让各种产品的质量最大化。那对第二阶段的bug数这意味着什么呢？它意味着我们应该非常强烈地意识到找出那些bug我们所付出的代价，并确保它有所值。
结论
那些曾由于对Bug数目感兴趣，而被我在会议中严厉责骂的伙计们，在整个软件开发生命周期（SDLC）中， 只要你们能够承认Bug在不同阶段出现的数量及其原因，我也非常愿意加入到你们之中，并乐于接受这个结果。
