批驳:单元測试自己測效果不好,别人測效果才好
2017-04-14 09:55
148 查看
有一种说法:程序猿測自己的代码效果不好。由于測试是找错。程序猿不愿意去证明自己是错的,别人測效果才好,对吗?这样的说法是根本错误的,误导了无数人。正好相反,单元測试要自己測效果才好。别人測则差点儿没有效果。除非有函数级的具体文档。
单元測试的三种方式:程序猿编码同一时候測试、程序猿编码后測试、由别人測试,成本的比例大概为1:3:5。測试效果的比例大概为5:3:1。这是指一般的开发过程,其特征是没有函数级的具体文档。
我们先来看看大家耳熟能详的几个概念:需求、设计、实现。需求是“要做什么”,设计是“具体怎么做”。实现是“做出来”。
写一个函数,无论写不写文档,需求、设计、实现仍然是必经的过程,仅仅只是面对的目标非常小而已。
写一个函数,程序猿要想清晰“要做什么”和“具体怎么做”,这是所想。显然,所想的就是需求和设计。把代码写出来则是实现。这是所做。
假设在写代码同一时候測试。測试用例一定是根据“所想”而设计的。測试的结果是验证“所做”是否符合“所想”。也就是说,測试的结果是:验证实现是否符合需求。这样的方式,需求是清晰的(尽管仅仅是在程序猿的脑子里),所以效果最好,而用例仅仅需根据“所想”直接设计即可,还可以利用測试来驱动开发,所以成本最低。
程序猿编码后測试,“所想”已经忘了一部分,要根据代码来“恢复”,可是不可能所有“恢复”。測试的结果。有可能是“验证实现是否符合需求”,也有可能不是,所以效果会打折扣,由于要花时间来“恢复”所想,且不能利用測试来驱动开发。所以成本也会高得多。
由别人測试,用例设计的根据是什么?除非程序猿在编码时把“所想”记录下来。形成函数级的具体文档,否则,“别人”仅仅能读代码来确定需求,实际上,这个“需求”是实现本身,測试的结果是:验证实现是否符合实现,俗称“跟着代码走”。这样的測试有什么意义?成本方面。须要读代码来确定需求。无疑非常费时间。所以成本最高。
举个简单的样例来说明。程序猿要一个加法函数。结果写成了:
编码时測试,程序猿一定知道自己要写的是加法函数,用例为a=1; b=2;ret==3,当然能发现错误。
编码后測试,程序猿有可能想起这是加法函数,測试能发现错误。也有可能忘了,读代码后觉得这是一个减法函数,这样測试就没意义了。
别人測试,仅仅能读代码,觉得是减法函数。測试没意义。
当然,实际的情形不会那么单纯,代码可能有一些凝视。“别人”或许能了解代码的大致需求。所以“别人”測试也会有一些效果。可是,单元測试主要做的,是找出实现与需求之间的细微偏差,比如。一些输入下代码是正确的,一些输入下。代码有问题(未分类处理这些输入或处理错误),“别人”即使可以了解代码的大致需求,也难于了解所有需求。測试效果总是非常有限的。
或许有人会说。边编码边測试,尽管根据的是代码的需求(小需求),可是这个需求是否符合系统的总体需求(大需求)呢?换几句话说,本来这个函数要做的是A功能。但程序猿所想的是B功能,那測试不是没有意义吗?一、由别人測试,跟着代码走,这个问题相同存在;二、这样的错误在集成后非常easy发现;三、这样的错误非常少。用小需求不一定符合大需求来否定程序猿測试自己的代码。那就是因噎废食了。
总之,一般情形下,程序猿编码同一时候測试、程序猿编码后測试、由别人測试。三种方式的成本的比例大概为1:3:5。測试效果的比例大概为5:3:1。这个比例仅仅是定性,我无法精确证明,信不信由你,反正经过十多年的实践,我是信的。
单元測试的三种方式:程序猿编码同一时候測试、程序猿编码后測试、由别人測试,成本的比例大概为1:3:5。測试效果的比例大概为5:3:1。这是指一般的开发过程,其特征是没有函数级的具体文档。
我们先来看看大家耳熟能详的几个概念:需求、设计、实现。需求是“要做什么”,设计是“具体怎么做”。实现是“做出来”。
写一个函数,无论写不写文档,需求、设计、实现仍然是必经的过程,仅仅只是面对的目标非常小而已。
写一个函数,程序猿要想清晰“要做什么”和“具体怎么做”,这是所想。显然,所想的就是需求和设计。把代码写出来则是实现。这是所做。
假设在写代码同一时候測试。測试用例一定是根据“所想”而设计的。測试的结果是验证“所做”是否符合“所想”。也就是说,測试的结果是:验证实现是否符合需求。这样的方式,需求是清晰的(尽管仅仅是在程序猿的脑子里),所以效果最好,而用例仅仅需根据“所想”直接设计即可,还可以利用測试来驱动开发,所以成本最低。
程序猿编码后測试,“所想”已经忘了一部分,要根据代码来“恢复”,可是不可能所有“恢复”。測试的结果。有可能是“验证实现是否符合需求”,也有可能不是,所以效果会打折扣,由于要花时间来“恢复”所想,且不能利用測试来驱动开发。所以成本也会高得多。
由别人測试,用例设计的根据是什么?除非程序猿在编码时把“所想”记录下来。形成函数级的具体文档,否则,“别人”仅仅能读代码来确定需求,实际上,这个“需求”是实现本身,測试的结果是:验证实现是否符合实现,俗称“跟着代码走”。这样的測试有什么意义?成本方面。须要读代码来确定需求。无疑非常费时间。所以成本最高。
举个简单的样例来说明。程序猿要一个加法函数。结果写成了:
int fun(inta, int b) { return a - b; };
编码时測试,程序猿一定知道自己要写的是加法函数,用例为a=1; b=2;ret==3,当然能发现错误。
编码后測试,程序猿有可能想起这是加法函数,測试能发现错误。也有可能忘了,读代码后觉得这是一个减法函数,这样測试就没意义了。
别人測试,仅仅能读代码,觉得是减法函数。測试没意义。
当然,实际的情形不会那么单纯,代码可能有一些凝视。“别人”或许能了解代码的大致需求。所以“别人”測试也会有一些效果。可是,单元測试主要做的,是找出实现与需求之间的细微偏差,比如。一些输入下代码是正确的,一些输入下。代码有问题(未分类处理这些输入或处理错误),“别人”即使可以了解代码的大致需求,也难于了解所有需求。測试效果总是非常有限的。
或许有人会说。边编码边測试,尽管根据的是代码的需求(小需求),可是这个需求是否符合系统的总体需求(大需求)呢?换几句话说,本来这个函数要做的是A功能。但程序猿所想的是B功能,那測试不是没有意义吗?一、由别人測试,跟着代码走,这个问题相同存在;二、这样的错误在集成后非常easy发现;三、这样的错误非常少。用小需求不一定符合大需求来否定程序猿測试自己的代码。那就是因噎废食了。
总之,一般情形下,程序猿编码同一时候測试、程序猿编码后測试、由别人測试。三种方式的成本的比例大概为1:3:5。測试效果的比例大概为5:3:1。这个比例仅仅是定性,我无法精确证明,信不信由你,反正经过十多年的实践,我是信的。
相关文章推荐
- 批驳:单元测试自己测效果不好,别人测效果才好
- 批驳:单元测试自己测效果不好,别人测效果才好
- css星级效果总结 取别人另加入自己的一些东东
- 密码发生器(在对银行账户等重要权限设置密码的时候,我们常常遇到这样的烦恼:如果为了好记用生日吧,容易被破解,不安全;如果设置不好记的密码,又担心自己也会忘记;如果写在纸上,担心纸张被别人发现或弄丢了)
- 密码发生器 在对银行账户等重要权限设置密码的时候,我们常常遇到这样的烦恼:如果为了好记用生日吧,容易被破解,不安全;如果设置不好记的密码,又担心自己也会忘记;如果写在纸上,担心纸张被别人发现或
- 别人的 App 不好用?自己改了便是。嘿嘿嘿 篇
- 别人的 App 不好用?自己改了便是。嘿嘿嘿 篇
- 别人的 App 不好用?自己改了便是。嘿嘿嘿 篇
- 利用Continuous Testing实现Eclipse环境自己主动单元測试
- 先做别人的例子,让自己去理解,比看书效果要好——只看不写,永远都不会
- 敏捷自己主动化測试 (黑盒单元測试)
- 照着别人的demo自己试着做了个放大镜效果
- apache如何不被别人的域名指向,Apache禁止别人的域名指向到自己的服务器
- 周鸿祎,高司令 2010-09-28 00:41 27469人阅读 评论(185) 收藏 举报 还是感到有必要将自己的一些想法快速记下来。 首先是对周鸿祎新员工演讲的看法。 就说实话这一点来说,周鸿祎比很多人强。所以我比较喜欢引用他的话,确实比较实在,不装逼。 至于一个公司招人的风格,是公司自己定的,别人也无权评价。有人说周是画大饼,忽悠员工卖命。废话,难道新员工讲话还有别的目的吗? 但我不认为周的选人思路在别的公司可以通行。原因是这样的:近十几年来,我们听到很多人有类似的说法,比如我们公司不要
- average pool对detection效果不好?
- 自己学驱动13——内存管理单元MMU(虚拟地址和物理地址)
- 鼓励别人,自己快乐,让我们享受快乐吧
- 别人叫我程序猿,我称自己攻城狮。没日没夜写代码,不知何日涨工资?