所有代码都需要单元测试覆盖吗?

发表于:2014-4-01 11:14  作者:WEB开发者   来源:51Testing软件测试网采编

字体: | 上一篇 | 下一篇 |我要投稿 | 推荐标签: 测试技术 单元测试

   单元测试(unit  testing)已经越来越得到广大开发者的认可。作为低成本、速度快、稳定度高的自动化测试手段,单元测试可以在类和函数级别对代码进行质量守护,有助于避免尴尬、耗时的错误。当然,相比功能测试(Functional testing)和端到端测试(end-to-end testing),单元测试能够寄予的产品级别的信心要略低一些,因而各个粒度的测试应该是相辅相成的,互为补充。
  常常听到一些组织要求开发团队提高单元测试覆盖率,换来的却是怨声载道,或者是一堆应付差事的垃圾测试(没有断言的测试,都见过吧)。尽管,低测试覆盖率意味着对质量的信心不足,但是,单元测试覆盖率真的要达到100%才好吗?
  100%听起来肯定比95%要好,但是区别在于那些额外测试的价值对你可能是微不足道的。这要看哪种代码没有被测试覆盖,以及你的测试能否暴露程序的错误。100%的覆盖率并不能够确保没有缺陷——它只能保证你所有的代码都执行了,而不管程序的行为是否满足要求。与其追求代码覆盖率,不如将重点关注在确保写出有意义的测试。
  测试越多,额外测试的价值越少。第一个测试最有可能是针对代码最重要的区域,因此带来高价值与高风险。当我们为几乎所有事情编写测试后,那些仍然没有测试覆盖的地方很可能是最不重要和最不可能破坏的。
  编写一些测试是不费脑筋的,但随着我们接近完全的代码覆盖率,我们不那么确定了——我们差不多已经为一切都编写了测试,而剩下的没有测试的代码是微不足道,几乎不会破坏。这就是所谓的收益递减。要想从单元测试中获得更多的收益,需要重新将单元测试从质量工具定位成设计工具。TDD等方式可以帮助我们做到这一点。
  换句话说,向代码基增加100个精挑细选的自动化测试是明显的改善,但当我们已有30000个测试时,这些额外的100个测试就无足轻重了。
  比赛场上的赢家是那些将注意力集中在赛场上的选手,而不是紧盯着计分板的人。—巴菲特
  总之,当你觉得生产环境中报来的bug很少了,或者你能够自信地对代码随时进行修改,单元测试就已经足够多了。
  另一方面,也有些观点认为,不但不值得追求高覆盖率,甚至写单元测试本身就是非常耗时和难以维护的重复工作。这种极端观点我同样不赞同。
  代码覆盖率不能告诉我们代码质量的高低,也不能用了评判开发人员的绩效。但它能够告诉我们哪些代码还没有被测试覆盖,哪里有漏网之鱼。至于这鱼值不值得抓,还是取决于开发人员的经验进行风险判断。那么,接下来我们再来分析一下,到底哪些鱼值得抓。

【有奖活动】填问卷 送70G测试大牛精品资料(干货+视频)!
21/212>

评 论

论坛新帖

顶部 底部


建议使用IE 6.0以上浏览器,800×600以上分辨率,法律顾问:上海瀛东律师事务所 张楠律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2018, 沪ICP备05003035号
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪公网安备 31010102002173号

51Testing官方微信

51Testing官方微博

扫一扫 测试知识全知道