为了发现数量众多的Bug而欢呼？

        英文原文：Seth Eliot，编译：一淘 – 惠如

        这不是一篇关于软件测试人员的工作评论方面的文章。最近参加了一个测试总结会，至少在两个项目汇报过程中发现，开发管理者感兴趣的一个度量指标 是：你们发现了多少个 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 在不同阶段出现的数量及其原因，我也非常愿意加入到你们之中，并乐于接受这个结果。