软件测试以bug数来考核,软件测试能力提升及其思考

如果

虽然Bug的数量也是衡量软件测试人员绩效方式的一种，但是这种单纯的以Bug数量作为测试人员的绩效考核方式在我看来不太合理。该方式可能会产生许多无效的Bug，增加测试和开发的沟通时间。如果作为测试领导或测试负责人我们应该避免使用该方式作为考核标准，以下是我认为不合理的几种原因：

1、测试模块安排不合理

如果安排测试稳定的模块不管是根据用例还是自由测试找到Bug的难度非常大，导致测试人员的Bug数量上不去，而测试新功能模块则存在的问题比较多，测试该模块的测试人员能找到Bug的难度就相对来说比较容易，Bug数量自然就上去了；

稳定的模块就是经过几轮测试之后修改合入较少的模块，如第一轮测试出来的Bug数量肯定多于第二轮测试，第二轮测试阶段的测试人员发现的Bug数量大概率比不上在第一轮测试过程中发现Bug的数量。类似于维护项目的回归测试基本很少有Bug了，任凭你投入的人力和时间再多，也很难发现Bug。因此模块的稳定性、模块的复杂度决定了测试人员找Bug的难度。

2、Bug的严重程度

找出测试对象的一般等级的Bug相对容易，而找出测试对象中严重等级的Bug可就困难多了，不仅需要测试人员对被测试对象功能和业务熟悉，还需要测试人员有丰富的测试经验。一个致命和严重的Bug的价值远远大于一般Bug的价值，如果仅凭Bug数量的多少而不考虑Bug的严重程度根本无法衡量测试人员的能力，因此单一的Bug数量作为考量有失偏颇。

3、软件测试