这不是一篇关于软件测试人员的工作评论方面的文章。近参加了一个测试总结会，至少在两个项目汇报过程中发现，开发管理者感兴趣的一个度量指标是：你们发现了多少个bug？然后，当得到的回答是一个很高的数目或是一个很严重的缺陷（如：3个严重的bug！），会得到热烈的鼓掌。

　　不过，我感觉这样做是不对的！我的第一反应是，好吧，让我换种说法……

　　“在我们的产品中，我们在设计和实现过程中出现了多少严重的缺陷？”“仅仅3个？”“太棒啦！（鼓掌）”

　　或者是：“哦，测试团队，你找出了多少个我们程序的致命错误？”“才3个？”，带着得意的笑容，“感谢测试团队（鼓掌）”

　　这表明，询问“多少个bug？”是种错误的方法，像这样的事情，我一旦发现会严厉地批评。但后来我意识到，这个特有标准的诱惑也曾让我深受其害，不仅在我过去无知的岁月中，甚至更多的是现在。为什么呢？对“多少个bug”的有效性来说，这意味着什么呢？ 下面是我的一些观点。

　　三个阶段

　　软件开发的生命周期可以按多种不同的方式进行切分。在这里，按我的观点，我会把它描述成3个阶段（见上图）。

　　● 阶段1：设计、开发、单元测试

　　● 阶段2：功能测试、上线前的评估测试：性能测试、压力测试、使用场景模拟

　　● 阶段3：线上监控、线上测试、客户反馈

　　上面列出来的项目是我们在每个阶段参与的以质量为中心的活动。

　　当我们询问发现了多少bug的时候，我们是针对第二阶段。所以问这个问题本身不是错误的，错误在于我们忽略了第一和第三阶段质量的影响和贡献。

　　阶段1的质量

　　在这篇博客开头，我开了一些玩笑，我现在想说的是第二阶段的高bug数意味着第一阶段质量下降。当开发总是主导设计，一个可靠的质量将会来自测试（系统的可用性和可测性）和项目管理（客户至上）的贡献。开发完成的质量不仅仅依赖于好的开发经验，当测试驱动开发（TDD）被用上的时候，还跟单元测试紧密相关。除此之外，单元测试也能让我们对“所得是否所需”有个基本的了解。