John Stone

1996-04-04

中国 河北

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

芦苇小白

Dec 29, 2020 12:45:23 PM 95

经典名言

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

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

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.csdn.net/test_beginner/article/details/1733689

拖动滑块验证
验证通过 验证失败

全部评论