什么是测试覆盖率?

顾名思义,软件测试对被测程序的测试范围的度量指标,用以评价测试的完全程度。最常用的测试覆盖率评测方法是基于需求的测试覆盖率和基于代码的测试覆盖率。

基于需求的测试覆盖率,不难理解就是指一条设计需求至少有一个测试用例对其进行验证。实际评测中有两种方法,一种是设计需求所对应的测试用例执行后即认定获得对该条需求的测试覆盖,也可以只将执行通过了的测试用例所对应的需求认定为被覆盖,通常二者均可被接受。基于需求的测试覆盖率的高低主要取决于,测试人员是否对每一条设计需求都有针对性地创建和执行测试用例。

基于代码的测试覆盖率,则是从代码层面度量测试执行范围的指标,通过统计有多少/哪些代码在测试中被执行到了来衡量测试的完全度。按照统计的准则的不一样,往往分为语句覆盖、分支覆盖、修正的条件/分支覆盖(MC/DC)、函数覆盖和函数调用覆盖等多种测试覆盖率类型。基于代码的测试覆盖率提供了对测试完全度更精确的量化指标。

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

简言之,测试覆盖率是通过量化“软件哪里有被测试过,哪里没有被测试过”来保证测试的完全性。诚然,没有完美的软件,也没有100%充分的测试用例,但用户至少可以通过测试覆盖率指标来评价测试的完全度是否达到了预期 –– 很显然,测试工作结束后,若是依然有为数众多的需求或者代码都未被测试覆盖到,将是一件需要被谨慎对待的事情。

所以,对于有较高可靠性或安全性的软件系统来说,通过评价测试覆盖率来提高测试的质量是非常有效且有必要的手段。

另一方面,无论是功能安全SIL/ASIL,还是适航认证,所执行的IEC 61508/ En 5018/ ISO 26262/ DO-178B, DO-178C标准中都对软件的测试覆盖率做了明确的要求。如下图SIL认证要求所示:

测试覆盖率-1

-- HR: Highly Recommended

-- R: Recommended

Entry Points Coverage: 入口点覆盖。最基本的测试覆盖率类型,现在在很多行业中更多地被以‘函数覆盖’和‘函数调用覆盖’的标准被执行,要求软件中所包含的函数至少有被执行和调用到,避免测试的明显遗漏或出现荣誉代码。 

Statement Coverage: 语句覆盖。SIL Level 2, ASIL Level B, DO-178B, DO-178C Level C以上等级的认证都要求软件测试达到语句覆盖,以保证每个可执行的代码行在测试中至少被执行了一次。比如下面的语句只要一个测试用例即可以满足该语句被测试覆盖到。

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

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

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覆盖率要求条件判定语句中的每个子条件都独立地影响条件判定结果。换句话说,条件判定语句中的每个子条件都在其它条件不变的情况下改变了条件判定结果。举个例子,

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

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

测试覆盖率-2

                                                                                                                图:MC/DC条件对

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


难点和挑战

  • 统计代码测试覆盖率势必要对测试代码进行插装,而插装膨胀率太大、或者编译器不兼容、或者插装算法不成熟,都会导致插装后无法正常编译或者运行

  • 只能统计上位机软件的测试覆盖率,无法支持嵌入式式环境

  • 只能统计单一测试环节的测试覆盖率,比如仅支持单元测试的覆盖率,无法统计系统测试覆盖率

  • 多次测试执行的测试覆盖率无法累加,需要重复集中执行

  • 测试覆盖率报告不直观、不易理解

解决方案

  • 基于需求的测试覆盖率和追溯关系。通过建立设计需求与测试用例的追溯管理来保证,“基于需求的测试”用例对需求的完整覆盖

  • 自动统计单元测试、集成测试等模块级别的测试覆盖率

  • 自动统计系统功能测试的测试覆盖率

  • 支持不同级别的测试环节之间的测试覆盖率叠加及增量分析

  • 完美支持各种嵌入式目标机环境和上位机平台

  • 统计语句覆盖、分支覆盖、MC/DC覆盖、函数覆盖和函数调用覆盖等常用的测试覆盖率类型

  • 运行时的动态测试覆盖率统计

  • 动画回放测试覆盖过程

  • 完全符合适航和功能安全等高可靠性行业认证标准的解决方案

相关资源

  • 白皮书

  • 新闻资讯

  • 通过确保测试的完整性控制产品质量_白皮书

    点击下载

  • 如何评估嵌入式软件测试工具_白皮书

    点击下载

  • 如何开发高质量的软件_白皮书

    点击下载

  • 人工分析覆盖率_白皮书

    点击下载

  • 利用Wind River VxWorks7实现自动化软件测试_白皮书

    点击下载

  • 2015软件测试技术报告_白皮书

    点击下载

RELATED RESOURCES

下载申请

是否需要技术支持

验证码

温馨提示:

我们将通过电子邮件向您发送下载地址,请核对您填写的工作邮箱是否正确。

提 交