代码覆盖率 vs. 测试覆盖率
代码覆盖率通常指跑完测试后, 由工具自动统计的在跑测试的过程中被测代码的覆盖率, 细分的话包括语句覆盖率, 分支覆盖率, 函数覆盖率等. 由于代码覆盖率可由工具自动产生, 采集成本非常低, 而又比较直观, 所以历来受到开发团队及管理者的欢迎, 有的组织甚至将其作为 KPI 指标之一。
然而围绕着代码覆盖率, 有很多有趣的事情, 尤其是将其作为 KPI 的时候. 你会发现, 长期在低位徘徊的代码覆盖率, 突然之间会有一个比较大的提升. 究其原因, 是开发团队在短时间内加了”测试”. “测试”是打引号的, 因为当我们近距离观察这些”测试”的时候, 会发现通常是调用了某个高层的入口函数, 因而牵出很多底层函数, 覆盖率就上去了, 然而, 没有一个断言(assertion), 或者是区区几个断言. 也就是说, 把产品跑了一遍, 但没有判断其行为是否符合预期, 而代码覆盖率突然就达标了。
尽管对于追求自我改进的团队来说, 不会这么掩耳盗铃, 代码覆盖率依然是有价值的反馈指标, 但这从侧面说明了代码覆盖率并没有表达出我们对于外部质量真正的关注点. 那么我们对于质量真正的关注点是什么呢?
是断言的覆盖率, 即测试覆盖率. 换句话说, 我们真正关心的是, 我们总共应该有多少测试用例/验收条件/检查点, 它们中有多少已经被覆盖了, 即做出了真正的断言. 但目前为止, 还没有工具能自动统计跑完测试后, 测试覆盖率是多少. 代码覆盖率仅仅是无法自动统计测试覆盖率时的一个替代品。
为了统计测试覆盖率, 需要准备分子和分母的信息. 分母是产品”完整”的测试用例列表, 分子是已经执行的测试用例列表, 包括手工和自动. 如果你关心测试覆盖率, 而手头又没有这两个东西, 就要开始准备了。
注1: 利用现有的 xUnit 测试框架, 可以在某种程度上得到测试覆盖率. 比如可以将”完整”的测试用例列表用 xUnit 的测试用例表达出来, 其中对于还没实现的, 设置为 ignore. 这样可以从最后的报告中看出总数, 和 ignore 的数量(当然如果你不做断言, 还是白搭). 现在更多的是借助管理工具甚至 Excel, 来手工维护”完整”的测试用例列表及状态. 如果你知道有更好的方式, 请告诉我.
注2: 前面”完整”的测试用例列表, “完整”一直打着引号, 因为这是一个无法证明的问题, 我们只能根据经验设计测试用例, 无法保证其完整性, 并且随着产品的开发, 这个列表也会动态更新. 至于如何让测试用例尽可能完整, 是组织应该投入的地方。
此测试覆盖率 vs. 彼测试覆盖率
基于前面的描述, 那么当我的测试覆盖率达到某个比较高的数值, 比如80%, 是不是我就可以比更低的数值比如20%, 对产品更有信心呢? 答案取决于你的测试用例的设计。
我们都听过80/20原则. 比如用户80%的时间在使用20%的功能, 20%的功能就可以支撑起用户最关键的业务场景. 那么, 如果80%的测试覆盖率, 覆盖的是那不常用的80%的功能, 而20%的覆盖率, 覆盖的恰恰是最常用最关键的那20%的功能, 那么, 你是否还像开始那样, 相信80%的覆盖率带来的安全感呢?
基于测试覆盖率很难达到100%这个前提, 基于我们的发布时间总是很紧张而又要保证质量这个前提, 我们必须投入精力, 做测试用例的价值分析, 挑选出最有价值的测试用例, 优先安排资源实现和运行。
如果团队的测试用例没有经过价值分析, 没有优先级划分, 那么这就是接下来马上应该做的事. 这牵扯到一个问题, 测试人员及测试技能的价值。
当我们谈论测试技能时我们在谈什么
最近几年随着自动化测试框架的流行, 评价一个人员测试能力的标准逐渐变成了是否能写自动化测试. 如果照这个标准, 所有的开发人员一夜之间都具备了合格的测试能力. 这显然是一个不成立的结论。
测试至少分测试用例的设计和测试用例的编写执行两部分. 自动化测试的长处仅仅在于编写执行. 使用自动化测试框架并不会自动让我们的测试更有效, 更完备, 更具洞察力. 而测试的有效性和完备性, 通常是我们更关注的. 然而遗憾的是, 通常组织中这方面的知识比较欠缺, 关注度不够, 技能交流较少。
如果我们交流测试知识时, 更多的是谈论 xUnit, RobotFramework等, 而不是等价类/边界值, 恶邻测试法/快递测试法, 关键路径分析等, 那几乎可以肯定我们遗漏了更重要的东西。
要在时间资源人力资源有限的情况下保证产品质量, 我们需要提高测试用例的设计能力, 价值分析能力, 安排合理的测试策略。
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
