文本

第6课–测试覆盖率并不能告诉你很多事情。

我觉得当今天的主题是测试覆盖率时,IT界的一些人有点太兴奋了。我从来没有理解过这种对数字的痴迷,而对你的产品的问题表现的却反而太少。 有一次,我为一位客户提供了80%的单元测试覆盖率作为必须达到的强制性标准。结果如何?他们必须创建一个“警察团队”来实际检查团队是否在进行有用的测试,因为许多团队试图通过在单元测试中声明true = true来制定规则。覆盖率是提上去了,但是却是胡扯。

另外,覆盖范围是什么意思?函数,行,语句,条件,分支,参数值,循环,状态…?...?

即使您拥有“完美的覆盖范围”,您也需要拥有完美的断言来配合它们如果您发现有意外的返回值(或其他副作用),则100%的代码覆盖范围将毫无意义。 代码覆盖率:会让您大吃一惊 即使具有保证没有副作用的微小功能(如上图所示),由于输入值的影响,可能的情况仍然很大,那么如何获得100%的覆盖率?好的,在现实世界中,总会有许多功能协同工作,所以不错,祝您覆盖率能够提升。

与其去争取较高的测试覆盖率,不如考虑覆盖哪些有用。请记住,我们正在寻找有用的信息,而不是为了赢得一些让人产生控制幻想的数字游戏。我确实同意Dan Ashby的观点,知道测试中根本没有涵盖代码的哪些部分非常有用!

但对我来说,就到这里为止了。我接受不确定性,测试不可能是完美的,风险是游戏的一部分。识别出最大的风险,并在那里投入大量的精力,如果愿意的话,增加这些领域的测试覆盖率,但是要知道这并不能保证软件没有错误。

author

石头 磊哥 seven 随便叫

company

thoughtworks

大家好,本人不才,目前依旧混迹于thoughtworks,做着一名看起来像全栈的QA,兴趣爱好前端,目前是thoughtworks 西安QA社区的leader,如果有兴趣分享话题,或者想加入tw,可以找我

roles

QA(营生) dev(front-end dev 兴趣爱好)

联系方式

如果想转载或者高薪挖我 请直接联系我 哈哈

wechat:

qileiwangnan

email:

qileilove@gmail.com