软件测试学习9-测试基础：软件测试覆盖率

一、测试覆盖率的概念

覆盖率是用来度量测试完整性的一个手段,同时也是测试技术有效性的一个度量，其特点有：

1. 通过覆盖率数据,可以检测我们的测试是否充分
2. 分析出测试的弱点在哪方面
3. 指导我们设计能够增加覆盖率的测试用例，有效提高测试质量，但是测试用例设计不能一味追求覆盖率，因为测试成本随覆盖率的增加而增加。

测试覆盖率对于黑盒测试来说，包含两个方面：

需求覆盖：它表示在测试中，有哪些函数被测试到了，其被测试到的频率有多大，这些函数在系统所有函数中占的比例有多大通过设计一定的测试用例，要求每个需求点都被测试到。

需求覆盖率 = (被验证到的需求数量) / (总的需求总数)

用例覆盖：主要体现在我们每轮测试验证通过的用例数在总用例中的比重

用例覆盖率 = (验证通过的用例数量) / (总的用例总数）

需求覆盖与用例覆盖的差异

1. 需求覆盖检查的是功能是否完成，重点关注产品设计；用例覆盖检查的是功能是否完善，重点关注开发设计。
2. 需求覆盖进行业务分支覆盖；用例覆盖进行逻辑分支覆盖

二、测试覆盖率的应用

简单的测试覆盖率：本次测试执行的用例数 / 所有用例数；【针对职能：测试】

使用场景：
1. 一般对于大型系统测试要求覆盖率100%
2. 总用例数编写全面

审核机制：抽样验收

基于产品的测试覆盖率：已测试需求点 / 设计所有需求数；【针对职能：产品】

使用场景：
1. 无论大型项目或是小需求迭代都要求覆盖率100%

审核机制：抽样验收

基于白盒的测试覆盖率：单元测试代码覆盖代码行 / 总代码行；大多用于判断语句覆盖【针对职能：开发】

使用场景：
1. 更多时候要求覆盖率80%+
2. 更多用于考察研发人员

缺陷：
1. 覆盖率数据只能代表测试过哪些代码，不能代表是否测试好这些代码
2.容易遗漏逻辑、判断等场景

基于自动化的测试覆盖率：自动化覆盖的测试场景(测试用例)/所有测试场景(用例)

80/20原则：比如用户80%的时间在使用20%的功能，20%的功能就可以支撑起用户最关键的业务场景，自动化测试的用例选择更着重于这20%的核心功能
注意：自动化测试更着重于回归验证，没必要追求过高的覆盖率，而要考虑用例设计

三、测试覆盖率的意义

应用最多的地方在测试停止标准。

1. 单纯讨论测试覆盖率，在瀑布式开发模型中并不重要，但在螺旋式、敏捷开发模型中，由于不断迭代累加，很难确定哪些模块在开发过程中没有给予足够的测试
2. 在短迭代、 Devops中，更强调用单元测试覆盖率来评估不断增加的代码数量