软件测试以bug数来考核,软件测试人员的考核

测试以bug数来考核,软件测试人员的考核"/>

软件测试以bug数来考核,软件测试人员的考核

引用

删除

luming /   2011-07-29 21:55:08

其实感觉用代码行数考核开发人员挺好的。

首先，把代码行数做为考核开发人员水平的杠杆是否合适？开发就是代码工人啊。

1.   开发人员写出的代码量反应了一个人一段时期之内的工作量，开发的工作量就是围绕着敲代码进行的，代码越多，那么工作量越大，一个人的工作量越大，考核得分高也是应该的；

2.开发人员写出的代码多，从一个侧面反应了一个人的编程水平。为什么同样的质量水平的产品，有的人写出的代码多，有的人少呢？实则是因为对于需求、设计的理解水平的高低决定了开发人员对功能点实现的覆盖程度不一、深入程度不一。经验老道的开发人员能够统筹全局，找到整个系统的开发重点，然后再逐步深入，挖掘细节问题，直到最底层的细节，用汇编最好不过了。

那么为什么又存在那么多的争议呢，分析了一下，有如下原因：

1.        职责不分，不管管理人员、需求人员、设计员、DBA、编码人员等都实行一刀切的政策，全部按照代码行数这个硬指标去执行，自然不大合适；

2.       代码数量有了，但是质量如何还是值得商榷；为了追求高的代码数量，有的人甚至抄袭其他人的开发结果，这样造成众多的重复代码问题；另外一个问题就是出现很多不需要的内容，比如把一个功能包装成N个类来回绕，这些不需要的代码不仅仅反应了开发人员的业务能力不高，另外也白白的占用了开发人员的工作量；

3.        再一点，因为追求代码数量，对于复杂的系统，开发大多都浮于表面，很难深入的理解到需求层面；毕竟一个复杂的功能可能要耗费上几天的功夫，但是有这几天的功夫，不如去写更多的简单代码；对于有责任心的开发人员当然不会这样，可是对于一味迎合考评的人员来说，无疑是个捷径；但是对于系统的质量来讲并没有什么好处；

所以说考核很难做到绝对的公平，当然如果能在考核的时候，考虑到一些细节的问题，如何使考核政策更加完善才是我们追求的目标.

一般的考核规则可以参考：

1.        从测试那里返回的缺陷来考核开发人员比较好，但是容易造成开发和测试的矛盾；

2.        需求覆盖率(需求分解的合理性、可实现性)；

3.       功能点完成数以及合格率；

4.        单元测试、集成测试质量；

5.        有效代码比率

6.        功能点未实现数(没有完成的功能点被发现，是影响开发绩效的，但不是很合理，因为有些需求不明确，开发人员很难实现，尤其是分析系统，不是业务系统)；

7.        设计质量以及开发技能提升情况；

8.        其他(就看主管对你的看法了，比如工作态度啊之类的)；