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

英文原文:Seth Eliot,编译:一淘 – 惠如

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

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

“在我们的产品中,我们在设计和实现过程中出现了多少严重的缺陷?”“仅仅3个?”“太棒啦!(鼓掌)”

或者是:“哦,测试团队,你找出了多少个我们程序的致命错误?”“才3个?”,带着得意的笑容,“感谢测试团队(鼓掌)”

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

安息吧,bug!

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

 

三个阶段

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

 

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

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

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

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

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

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

阶段1的质量

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

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

阶段1的质量指标:

●  开发和测试、PM一起展开设计评审(双重检查);

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

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

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

●  静态代码检查;

阶段2的质量

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

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

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

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

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

● 集成测试代码的覆盖率(和往常同样的说明);

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

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

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

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

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

阶段3的质量

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

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

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

结论

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

收藏 评论

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部