文本
第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
