如何提高Bug敏感度

小议Bug敏感度

  在测试圈中，相信大家对“Bug敏感度”这一词并不陌生，但是Bug敏感度具体是指什么呢，本文对此关键词进行解读的基础上，对其与软件质量的关系，影响的关键因素，如何提高测试人员的bug敏感度进行分享。(--续集）

 

Bug敏感度的故事

 

【测试经理的评价】

在一次绩效评价中，A主管对某位测试工程师的评价如下：

本季度完成了模块A、模块B、模块C的系统测试工作，设计了1200用例，提交了500+Bugs，严重Bug占40%，Bug数占测试团队（同期参与项目有4人）的35%，其突出的Bug敏感度，对某项目软件质量的稳定有突出贡献。

 

【测试工程师的评价】

测试工程师A说：

陈生的Bug敏感度，真让我佩服得五体投地，昨天我们一起在实验室测试同一模块，相同的软件特性，他提交的其中有5个Bug，我是看到过的，其中有3个是当时没有注意到（没有发现），而另外2个我是看到了，但不知道是不是Bug，或者认为他是正确的，而是这2个Bug就在我眼皮底下悄悄地溜走了。呜呼！

  

【开发工程师的评价】

 

开发工程师B说：在提交代码前，我对着软件按照测试的Checklist执行了一遍，一切都正常。正在乐着呢，本次的版本质量一定高，心里还在想”嘿嘿！看你们测试人员能提什么Bug给我”。那知，才乐了一个上午，下午就有人叫我到现场看一个系统崩溃的Bug，更有甚者，此Bug在我的机子上我还不能重现，但一叫测试人员过来重现，其马上就出现了。原来测试软件可以怎么弯来扭去XXX操作的，这就是Bug敏感度！悲惨世界呀，够我用1-2天时间来折腾了。

 

读者朋友，找到答案件了吗，Bug敏感度对于测试人员来说，非常重要。特别地出现了一些显而易见的Bug，而你却视而不见，或并未识别到它是一个Bug，而遗漏到客户端，是测试人员的大忌！不言而喻，Bug敏感度对于一个测试人员的工作的重要性。但这个含金量极高的敏感度，如同一个道士的修炼，要想达到炉火纯青，正如“冰冻三尺非一日之寒,滴水穿石非一日之功”也，Bug敏感度是颇见功底的。

Bug敏感度与软件质量关系

 正如前面故事中提到，Bug敏感度高的测试人员，能在短时间内发现大量的Bug，从而在一定程度上提高软件的质量。从这个角度看，Bug敏感度与软件质量的关系是正相关的，如下图表示，即Bug敏感度越高，被揭露的Bug越多，对应模块或软件的质量相对越可靠。

 

 

同理，Bug敏感度不高，必然就会造成一些Bug遗漏，提高了软件质量的风险系数，我们可用Y=-kX来表达这个意思，见下图。Bug敏感越差，遗漏的Bug越多，软件质量的风险就越大。

 

 

 

 

 

但是软件质量的评价是一个复杂而多维度的，不仅仅与Bug敏感度有关系，还包括设计本身的约束、预防等先天因素。

 

  

提高Bug敏感度的关键因素

  影响测试人员判断某问题或现象是否是Bug，还是其他问题，有很多原因，下表是笔者总结的一些关键因素，与大家一起分享。

 

序号	因素	影响分析
1	业务熟悉度	不清楚业务，会不能很好地理解特性的用途，应用场景，会导致正确的判断，风险分析；
2	测试专业技术：测试思维	除常规的测试思路外，逆向，相关影响或异常，多条件组合等特殊情况的专业思路能让迅速发现软件中潜伏的Bug。
3	测试专业技术：测试工具掌握	有些测试对象需依赖特殊工具生成数据、监控、检查，作为一种测试手段、方法，能发现某类型的Bug，如数据库性能测试，内存泄漏的检查等
4	学习能力	学习测试同事经验，包括与需求、开发人员的交流，从交流中增加经验、知识的积累等。学习有主动与被动，主动学习的人，进步快。
5	对开发者的了解	对合作的某开发人员了解多，知道对方可能出错的地方，例如某开发人员是新员工，对业务不太熟悉，容易在模块接口处理上考虑不周，易犯错误，则可以有针对性测试这些方面。
6	系统繁杂度	了解系统的设计，清楚最繁杂的设计，最核心的设计，然后重点分析这些部分，找出测试的重难点

 

说明：

关于学习能力，有些同学可能理解存在误区，或者比较片面，认为学习就是捧着书本看书。常听一些同学说，正在看C+编程，Android开发，网络通信相关书等，当然没错，这些都是在学习。但是否有更直接的体现学习能力的方法呢。曾经在一位同事的总结中读到：通过参与同项目外专业组的讨论，大受启发，回来一试，发现了2个严重的系统接口方面的bug，及一个我们未曾考虑到的系统设计需求。这种通过与他人的交流获取的直接知识，并不一定能在书本上看到的，但它也是一种学习。学习有直接学习，简接学习。如果说简接学习是夯实基础，那么像上述通过交流、实践的方式直接地学习的方法是取人之长，补已之短的快速通道。

觉得笔主写得很好，转载了