在测试阶段中，按bug的数量评定开发人员的标准是否靠谱？

本博客已经迁移，本文对应新博客链接：http://blog.321aiyi.com/article/381

经典名言

提到这个问题， 我想到了一句流传在程序员之间的经典名言：

按代码的行数评估开发的标准就像按重量评估飞机的质量一样愚蠢。

bug和代码量这两种平不标准， 有相同之处， 也有不同之处。那么，用bug的数量来评估开发质量到底靠不靠谱呢？

很幸运的，我遇到了这个问题那么这个评估标准的可行度到底如何呢？

---

一些似乎有用的评论

这些内容来自于网络人事的一些观点

• 通常情况下，bug的多少与参与程序员无关

这个不能一概而论
在某些地方，某些疯狂的程序员可以一天写好一个网站
而软件工程方面的书籍却告诉我们一天提交1、2百行代码就OK
所以，bug的多少基本上和程序员无关
和区域及社会观念有关
这个也应该叫地方特色。

(注意: 这里引用的意思中地方特色指的不是特色社会主义, 而是指一些时期由一些资本控制下形成的社会状况, 这是社会发展所经历的必然阶段. 希望网友不要过度解读)

• bug的严重性相对于bug数量而言更有效，软件出现缺陷，程序员不是唯一责任人

代码不是以行计数的，Bug也不是以数量为标准的…
一个项目出100个可以立即修正的Bug可以原谅，一个项目出一个致命Bug不可原谅…
一个项目出100个可以被测试人员发现的Bug也可以原谅，一个项目出一个被用户发现的Bug不可原谅…

• 出现bug是正常的， 不应该成为评估标准

伟大的领袖说过,这个世上只有两种人不会犯错误,死人和为出生的人.
所以我们是人都会犯错误.
BUG是不可避免的.
世界五百强其中一家软件质量保证
单位:每千行代码
单体测试: 9.3 结合测试: 3 UAT测试: 1
就这个数字左右,找不出这么多bug测试深度不够,我们的经验一般会稍微高于这些数字.

---

网上的评价呈现一边倒的趋势…额，既然如此那肯定存在一定的道道儿。仔细分析下，无外乎是下面这几种场景的问题：

需求场景

在我的圈子里，有这么一句话需求越简单，开发越复杂；需求越复杂，开发越简单。这句话的意思指的是：当一份需求过于简单没有复杂的要求时，他的不确定因素就越多。这种因素直接导致了测试的质量以及开发的质量。

举个简单的栗子（非实际场景）：点击“尚未配置字段”链接，进行字段配置并保存。
需求简简单单一句话， 但他的不确定因素太多了。
比如点击链接后是新打开一个页面还是页面弹出模态框进行配置？
再比如配置保存后，“尚未配置字段”的字样是否需要进行更改？改成啥？以及配置时字段格式是什么?有没有长度限制?
通常一个不小心，你就会被惯性思维的认为需要做成XXX，而产品想要的是OOO，但测试认为的是FFF。而领导觉得NNN更好一些。那么可以想象将来的BUG数量了。

同样是上面那句话需求越简单，开发越复杂；需求越复杂，开发越简单。，上面讲的是不确定因素造成的，除了这些还有实际开发的复杂程度。通常会有看似很简单的需求开发起来异常困难的例子。

再举个真实的栗子： 比如某银行产品经理要求程序员实现一个根据手机壳颜色自动更换APP主题色的需求。
首先打人是不对的（捂脸哭）作为程序员，本就弱势的你，为什么不好好和他解释呢？

比如：
A:我不能接你这个需求
B:为什么？
A:要实现这个功能，我需要至少两年的时间，这不符合公司本次版本规划。
B:WTF？
A:完成这个功能我需要知道手机壳的颜色，目前国内没有这种技术，甚至国外也没有。我可以考虑用眼球识别，识别出用户眼中的手机颜色，还要根据陀螺仪以及引力系统判断用户拿的是正面还是反面，启用正面摄像头还是背面摄像头，还要区分眼睛颜色，有的人是蓝眼睛这你知道的， 还有…
B:打住，我不管反正你要做。
A:好的，但这是一个非常重要的技术突破，我需要人手，至少20人的专业团队。你和我一起去向领导申请一下吧！
B:为什么我也去？
A:因为你不去的话领导肯定不相信有这么个需求（同时做出一副我嫩想做但领导不相信的样子）
B:那算了吧，反正这个需求是我脑袋一热临时加上的…

扯偏了，上面这个功能，在产品经理眼里可能就是一句话，并且软件本身看起来似乎没有多大的改动。但对于实现这个功能的开发者而言，则是一个灾难了。如果真的要实现的话，那么这项足矣申请专利的技术需要经历多少万次测试呢？那么测试过程中又会发现多少bug以及打回多少次呢？

人员分配

在一些开发中，可能会出现人员分配不均的问题， 也可能会出现分配的工作与开发人员不匹配的问题。只要不是自己领取的任务，通常都会存在这个问题。

在一些质量评审会上，总有bug最多的人，或许他们会说“我这次没做好，我会努力提高自己的能力”等之类的话，但更多的则是心里怒骂：“TMD你行你上呀！”。

这不是程序员有多么狂傲，一般这么说的人，实在是他开发的内容实际上就应该出现这么多的bug（可能有歧义，换句话说，即使换了别人还是会出现那么多的bug甚至更多）以至于没有任何理由可说了。不然哪个爱玩儿技术的的人认为自己技术不行呢？

工作量

对于每个人的工作量不同而言，出现bug的数量也不同。而这通常是挂钩的。如果按照下面的标准的话

单位:每千行代码
单体测试: 9.3 结合测试: 3 UAT测试: 1

一千行代码里，从开始开发到上线，正常情况下出现10个bug则在允许范围内。
假若A写了两千行代码，到投产总共出现了15个bug。
但B只修改了一句文案将“无权限操作”改为“操作失败，您的权限不足”，改动仅一行，同时因为这次改动产生了一个bug。
那么到底是A的质量差呢还是B的质量差呢？
如果从bug数量上看，A的bug量明显比B多了整整10倍。但没人会认为A差。因为如果B的工作量和A一样的话，按照这个比例B可能会出现两千个BUG了…

所以从工作量上而言，以bug数量作为评估依然是没有任何标准的。

#总结

再次回到开头的那句经典名言，通过这些整理，或许通过bug量来评估开发质量同样也像按重量来评估飞机质量一样。

#题外话
我又编辑了一次，因为我发现了这篇文章，这是一个以测试人员的角度去看待的同样的问题，给大家分享一下：https://blog.youkuaiyun.com/test_beginner/article/details/1733689