你真正需要的代码测试覆盖率是多少?

开发 后端
本文是从 How much code coverage do you really need? 这篇文章翻译而来。

我写这篇文章的起因是由于看了@unclebobmartin在微博上的一些看起来言之凿凿的话语。给那些不认识Uncle Bob的人介绍一下——他是我们软件产业里***的一个专家,是《 Clean Code(代码整洁之道)》这本著作的作者,是敏捷宣言(Agile Manifesto)的签署人之一。在上世纪九十年代,他对文献***面向对象实践方法贡献了很大的力量。所以,当他说话时,我们一定要关注一下。

他给我们日常的TDD和单元测试制订了一个***纲领。我们可以从他的微博里清楚的看到这点:

“两件事。可重复性和成本。跟自动化测试比起来,手工测试的成本高的可怕。”

“手工测试不是测试;那是在做实验。只要有人的因素牵涉其中,那结果就必然可疑。”

“你们告诉我的实际意思就是让我大开方便之门、不去测试某些程序。哼…”

“代码覆盖率100%并不是成绩,那是***要求。即使只写了一行代码,你也要测试它。”

他接着把软件测试跟在其它领域里常见的但被认为很关键的活动进行了比较:

“战地外科医生也许没有最够的时间做严格的消毒,但这带来的风险可能是死亡或高昂的治疗代价。”

“会计难道只会把80%的数据表做双份备份吗?”

“有多少回你们都看到了那些严重的宕机事故都是因为一些愚蠢的程序员以为那些愚蠢的代码不许要经过测试而导致的?“

他的所有这些观点都很有价值,但他只向我们展示了问题的一面。现实中并不是所有的应用都需要如此谨小慎微的测试。并不是所有的应用都跟战地手术或巨额资金核算那么重要。(更不要说在很多情况下的为”合理避税“而做的帐务:))。

一个更重要的原因是,100%的测试覆盖率并不能保证bug的不出现。就连Uncle Bob自己也承认:

”测试并不能杜绝bug。但测试能保证程序的行为是符合预期的。“

这很显然指的是:同一个程序员在程序里埋下的概念性或逻辑性错误,由他自己测是绝对测不出来的。

最终,所有的问题归结于ROI(投资收回率)和实用主义。有些应用比其它应用需要更多的测试。有些bug需要比其它bug投入更多的精力去修复。究竟是否需要在自动化测试是投入更多的时间和财力,或多少覆盖率是合适的还是过分了,这都需要人的主观判断。

【编辑推荐】

  1. 程序员如何在"小公司成长"和"大公司学习"
  2. 程序员工资禁忌 你可知道?
  3. 还有什么更伟大 患ALS程序员生前用脚写完***代码补丁
  4. 一个10年程序员职业发展、总结和困境
  5. 走进对日外包程序员的世界
责任编辑:金贺 来源: 博客园
相关推荐

2023-10-27 08:49:00

JCovOpenJDK

2013-08-28 10:44:01

LinuxLinux桌面

2012-03-16 21:08:25

手机

2017-04-13 10:08:30

软件开发开发

2019-10-23 14:26:32

云计算解决方案云服务

2019-09-09 14:50:40

网络攻击信息安全技术

2021-09-18 11:09:44

人工智能AI深度学习

2012-04-11 11:21:57

ibmdw

2022-03-10 06:41:06

SOC网络安全

2019-12-10 15:36:36

人工智能机器人技术

2019-09-25 09:20:41

谷歌代码开发者

2011-11-01 10:10:48

ScriptCover

2015-11-09 17:56:57

WebPHP函数覆盖

2016-01-13 10:14:15

WebPHP函数覆盖

2022-05-31 09:01:18

SwiftApp 项目

2020-05-21 08:47:11

工程师开发技术

2021-12-25 22:30:27

Chrome DevTJavaScript调试工具

2022-08-25 06:27:39

vivoJaCoCo代码覆盖率

2022-08-15 13:59:10

XaaS云计算

2012-09-21 10:30:56

Linux项目代码覆盖率
点赞
收藏

51CTO技术栈公众号