阶段1的质量指标：

　　● 开发和测试、PM一起展开设计评审（双重检查）；

　　● 需要结对review的代码的百分比。我的观点是--。这不仅是为了指出代码中的错误，更是一种重要的方式，能让高级开发人员指导更多初级开发人员使用更好的开发经验，比如采用设计模式和代码重用；

　　● 单元测试代码覆盖率。咦，我有提到过？一些人可能会想象这是一个有争议性的论断。但像bug的数目没有尽头，而是一个未知数一样，代码覆盖率也是；

　　● 代码覆盖率缺口分析：那些没有覆盖的代码，我们是否遗漏了什么？

　　● 静态代码检查；

　　阶段2的质量

　　我想阐明的一个主要观点是：当许多软件专业人员想到软件质量的时候，他们会想到这个阶段。这种观念的错误可以用一句谚语来概括：“质量不是测试可以测出来的”（如果有人知道这句谚语是谁说的，请告诉我下）。

　　这只是整个过程的一个阶段。有很多阶段1的质量评估方法在这有对应的部分：

　　● 测试计划是否被开发和PM review？

　　● 测试代码结对review的百分比；

　　● 集成测试代码的覆盖率（和往常同样的说明）；

　　然后是这个阶段特有的部分：

　　● 有记录的测试结果：这个对性能测试和压力测试尤为重要，因为它提供了我们所知的能在生产中接受的基准指标。

　　● 所发现的bug数目和严重程度。重点在这了，因为它是一个有效的质量/风险指示器。但它不能放在真空中，它必须和第1、第3阶段的结果在一起才能说明问题。

　　● 难道发现大量的、很严重的bug，意味着超级有效的第二阶段会把这个产品所有的风险排除？或者意味着阶段1质量非常糟糕时，我们可以期望更多的灾难折磨我们的客户？

　　● 难道一个很少的bug数意味着我们阶段2的工具是在浪费时间？或者意味着阶段1非常给力然后带来了高质量的代码？

　　阶段3的质量

　　我之前讲过线上测试（TiP），它是一个有效的针对软件产品的测试方法。这种方法的接受程度（不是方法本身）还有点新。然而线上监控不新鲜了。亚马逊是一个很好的例子，快速开发和良好支撑的监控工具，加上其它工具使得亚马逊能对产品发布作出快速响应（也是补丁），这已经成为亚马逊各种服务的质量保证制度的一部分。你也许会问，即使你能找到线上缺陷并快速修复，难道允许将这些缺陷带到生产中？“质量”，是的，你只要问问亚马逊的用户他们是否遇到过问题，或者看看亚马逊的用户满意分数明白了。

　　既然我们承认产品有一个合理的质量阶段，那为什么不在第2阶段把所有的问题找出来，而不用管第3阶段呢？问题的答案是成本。如果我们尝试用第二阶段的大规模预先测试找到所有的问题，那我们会因为不断增加的成本而得到越来越少的回报。在前面两个阶段的基础上，用上第3阶段是一个合理的、划算的方式，能让各种产品的质量大化。那对第二阶段的bug数这意味着什么呢？它意味着我们应该非常强烈地意识到找出那些bug我们所付出的代价，并确保它有所值。

　　结论

　　那些曾由于对Bug数目感兴趣，而被我在会议中严厉责骂的伙计们，在整个软件开发生命周期（SDLC）中， 只要你们能够承认Bug在不同阶段出现的数量及其原因，我也非常愿意加入到你们之中，并乐于接受这个结果。