功能测试之为什么要统计测试覆盖率?

lsekfe

什么是测试覆盖率？
　　顾名思义，软件测试对被测程序的测试范围的度量指标，用以评价测试的完全程度。最常用的测试覆盖率评测方法是基于需求的测试覆盖率和基于代码的测试覆盖率。
　　基于需求的测试覆盖率，不难理解就是指一条设计需求至少有一个测试用例对其进行验证。实际评测中有两种方法，一种是设计需求所对应的测试用例执行后即认定获得对该条需求的测试覆盖，也可以只将执行通过了的测试用例所对应的需求认定为被覆盖，通常二者均可被接受。基于需求的测试覆盖率的高低主要取决于，测试人员是否对每一条设计需求都有针对性地创建和执行测试用例。
　　基于代码的测试覆盖率，则是从代码层面度量测试执行范围的指标，通过统计有多少/哪些代码在测试中被执行到了来衡量测试的完全度。按照统计的准则的不一样，往往分为语句覆盖、分支覆盖、修正的条件/分支覆盖（MC/DC）、函数覆盖和函数调用覆盖等多种测试覆盖率类型。基于代码的测试覆盖率提供了对测试完全度更精确的量化指标。
　　为什么要统计测试覆盖率?
　　简言之，测试覆盖率是通过量化“软件哪里有被测试过，哪里没有被测试过”来保证测试的完全性。诚然，没有完美的软件，也没有100%充分的测试用例，但用户至少可以通过测试覆盖率指标来评价测试的完全度是否达到了预期 –– 很显然，测试工作结束后，若是依然有为数众多的需求或者代码都未被测试覆盖到，将是一件需要被谨慎对待的事情。
　　所以，对于有较高可靠性或安全性的软件系统来说，通过评价测试覆盖率来提高测试的质量是非常有效且有必要的手段。
　　另一方面，无论是功能安全SIL/ASIL，还是适航认证，所执行的IEC 61508/ En 5018/ ISO 26262/ DO-178B, DO-178C标准中都对软件的测试覆盖率做了明确的要求。如下图SIL认证要求所示：

Entry Points Coverage: 入口点覆盖。最基本的测试覆盖率类型，现在在很多行业中更多地被以‘函数覆盖’和‘函数调用覆盖’的标准被执行，要求软件中所包含的函数至少有被执行和调用到，避免测试的明显遗漏或出现荣誉代码。
　　Statement Coverage: 语句覆盖。SIL Level 2, ASIL Level B, DO-178B, DO-178C Level C以上等级的认证都要求软件测试达到语句覆盖，以保证每个可执行的代码行在测试中至少被执行了一次。比如下面的语句只要一个测试用例即可以满足该语句被测试覆盖到。

1. 　if((a || b) && c)

复制代码

Brach Coverage: 分支覆盖。 SIL Level 3, ASIL Level C, DO-178B, DO-178C Level B及以上等级要求测试的分支覆盖，集中在每个分支判定语句 -- 判定结果可以是TRUE或FALSE，以保证每个分支至少被遍历一次。还是下面的if语句为例：

1. if((a || b) && c)

复制代码

　为了满足该语句的分支覆盖率，至少需要2个测试用例来分别覆盖它的TRUE和FALSE这两个分支。所以我们在设计测试用例的时候需要考虑if语句中的判定条件，创造符合要求的测试输入参数。
　　MC/DC Coverage: 修正的条件/分支覆盖率。SIL Level 4, ASIL Level D, DO-178B, DO-178C Level A或和核安全级等最高安全等级的标准，除了要求以上测试覆盖率以外，还会要求MC/DC覆盖率。它是要求更高的测试覆盖率，更苛刻的覆盖条件。MC/DC覆盖率要求条件判定语句中的每个子条件都独立地影响条件判定结果。换句话说，条件判定语句中的每个子条件都在其它条件不变的情况下改变了条件判定结果。举个例子，

1. 　if((a || b) && c)

复制代码

　为了满足上面的包含a, b, c三个子条件的if条件判定语句的MC/DC覆盖率，我们需要设计至少4个（n+1）个测试用例，组成3对测试用例，让a, b, c分别独立地影响判定结果。如下图所示。

图：MC/DC条件对

即便是最有经验的测试工程师，要完成这个任务都是不容易的。所以MC/DC覆盖率一般只会在最高安全等级要求的项目，即软件错误可能造成众多人员死亡且发生概率不低的系统中被强制要求。

千里

覆盖率在工作中真心关注得少