你们见过公司有这样评价单元测试的吗？

zyszys001

系统测试的后续发现的缺陷与代码行的百分比：
小于0.1个BUG/千行代码—5分；；（经过单元测试后，系统测试的发现的bug要小于0.1个bug/千行代码，单元测试才能得5分）
小于0.2个BUG/千行代码—4分；；（经过单元测试后，系统测试的发现的bug要小于0.2个bug/千行代码，单元测试才能得4分）

小于0.3个BUG/千行代码—3分；；（经过单元测试后，系统测试的发现的bug要小于0.3个bug/千行代码，单元测试才能得3分）

小于0.4个BUG/千行代码—2分；（经过单元测试后，系统测试的发现的bug要小于0.4个bug/千行代码，单元测试才能得2分）

小于0.5个BUG/千行代码—1分"（经过单元测试后，系统测试的发现的bug要小于0.5个bug/千行代码，单元测试才能得1分）

1、项目是经过单元测试和系统测试。
2、评价单元测试是根据系统测试发现bug数来衡量单元测试好坏。
你们见过这么来评价单元测试的吗？是我们公司太牛了，还是我们公司太白痴了

dennyqiang

够牛的，这种公司。作为一种项目的监控指标，比较有作用(比如发现其数据与标准偏离太多的时候提出一些解决方法)，但是作为员工的工作业绩，或者项目成败的依据，这显然是一种非常不理智的行为。

如果作为一种硬指标来做要求，这显然是违背了人性化管理的要求的，这就有点像工厂里流水线似的管理了，对于IT从业人员，这一套不适用。这将会扼杀一个团队，团队的创造力等。

不过期待楼上的能在你们应用了这样一种管理模式以后谈谈你的体会，为我们大家提供一些新的Idea.

ujfjwkwvf

同意楼上的，这个只能作为项目的监控，如果做为员工的考核就很不标准，因为代码的难易程度不一样，每个测试员看问题的角度也不一样，一旦与人的利益挂钩，就会导致开发人员或测试人员的心理产生问题，不是为了项目找BUG,而是为了BUG数而找BUG。
容易让人浮躁，静不下心来分析BUG的原因，而变为争论其是不是一个BUG。

月上百合

标准制定超严格啊

momang

很牛

单元测试千行代码 0.1个bug  

到了集成 测试  和 系统测试

千行代码 50个以上

常青藤

确实不合理

stacy-2008

要用二分法来看待这个问题，首先，要问的是楼主的公司是做产品的还是项目的，如果是产品，我认为这样的要求是不过分的，当然其中还有一个隐含的条件就是开发的时间内要包含单元测试的时间。其实很多的外国公司都是这么要求的，只有这样才能控制住质量，这样做才能把成本控制在最小化。但如果做的是项目，还要看所给的时间是不是充裕，如果充裕，这样的要求也是合理的。但是没有预留单元测试的时间，那这个要求就是不合理的了。这些都需要辩证的眼光来看，没有绝对的对或者错。