软件测试基础之你的测试覆盖率是多少?

本文探讨了测试覆盖率在软件开发中的作用,包括需求覆盖率和代码覆盖率的定义、衡量指标、价值与局限性,以及JaCoCo等工具的应用。强调了代码覆盖率并非完美质量保证,需合理运用并结合其他测试策略。
摘要由CSDN通过智能技术生成

在面试过程中,遇到过面试官询问测试覆盖率的问题。

我说没统计过(完结撒花)。

开个玩笑。

通常测试覆盖率是用来「衡量测试的充分性和完整性」。

从广义的角度来讲,测试覆盖率主要分为「两大类」,一类是「面向项目的需求覆盖率」,另一类是「更偏向技术的代码覆盖率」。

一、需求覆盖率

需求覆盖率,是指测试「对需求的覆盖程度」。

通常的做法是将每一条分解后的软件需求和对应的测试建立一对多的映射关系,最终目标是保证测试可以覆盖每个需求,以保证软件产品的质量。

但是,在如今敏捷开发模式下,互联网项目中很少直接基于需求来衡量测试覆盖率了,而是「将软件需求转换成测试需求」,然后基于测试需求再来设计测试点。

所以,现在所说的测试覆盖率,通常默认指「代码覆盖率」,而不是需求覆盖率。

二、代码覆盖率

代码覆盖率,通常是指「至少被执行了一次的条目数」占整个条目数的百分比。

  这里的“条目数”,可以是代码语句,也可以是函数,还可以是路径,来对应不同的代码覆盖率类型的定义。

  1. 最常用的三种代码覆盖率指标

  「行覆盖率」 又称为语句覆盖率。指已经被执行到的语句占总可执行语句(不包含类似 C++ 的头文件声明、代码注释、空行等等)的百分比。

  这是最常用也是要求最低的覆盖率指标。实际项目中通常会「结合判定覆盖率或者条件覆盖率一起使用」。

  2. 判定覆盖

  又称分支覆盖。用以度量代码中「每个判断」的「取真分支」和「取假分支」是否各被覆盖「至少各一次」。

  比如语句if(a>0 && b>0),需要覆盖a>0 && b>0为 True 和 False各一次。

  3. 条件覆盖

  条件覆盖,是指判定中的每个条件的可能取值至少满足一次。度量判定中的每个条件的结果 True 和 False 是否都被测试到了。

比如语句if(a>0 && b>0),这里有2个条件输入,分别是a>0和b>0。那么就需要有a>0取True 和 False 各一次,同时要求b>0取True 和 False 各一次。
 

三、代码覆盖率的价值

  • 根本目的是找出「潜在的遗漏测试用例」,并有针对性的进行补充。
  • 还可以识别出代码中那些由于需求变更等原因造成的「不可达的废弃代码」。


  通常我们希望代码覆盖率越高越好,代码覆盖率越高越能说明你的测试用例设计是充分且完备的。

  「但是,也不能盲目追求过高的代码覆盖率,因为后面对于测试的投入成本会呈指数上升」。

  目前,主要是在单元测试阶段对代码覆盖率有较高的要求。因为很多测试条件在集成或者页面测试的时候不方便模拟,远不如在单元测试的时候用mock、打桩来实现。
 

四、代码覆盖率的局限
 

那么 100% 的代码覆盖率,是否就说明项目质量一定没问题呢?

  回答当然是:否。

  因为代码覆盖率的计算是「基于现有代码」的,并不能发现那些「未考虑某些输入」以及「未处理某些情况」而引发的问题。

  所以,它能反映的仅仅是「已有代码的哪些逻辑被执行过了,哪些逻辑还没有被执行过」。

  然后,我们依此为依据,可以补充测试用例,也可以去测试那些还没有覆盖到的执行路径等等。

「总结:高的代码覆盖率不一定能保证软件的质量,但是低的代码覆盖率一定不能保证软件的质量」。

五、代码覆盖率工具

通常,对于不同的语言,会有对应的一些工具。最常见的java,就有一个工具叫 JaCoCo。

JaCoCo 是一款 Java 代码的主流开源覆盖率工具,可以很方便地嵌入到 Ant、Maven 中,并且和很多主流的持续集成工具以及代码静态检查工具,比如 Jekins 和 Sonar 等,都有很好的集成。

1. JaCoCo 代码覆盖率报告

2. JaCoCo 详细代码覆盖率实例

  • 绿色的行表示已经被覆盖。
  • 红色的行表示尚未被覆盖。
  • 黄色的行表示部分覆盖。
  • 左侧绿色菱形块表示该分支已经被完全覆盖。
  • 左侧黄色菱形块表示该分支仅被部分覆盖。

通过这个详尽的报告,你就可以知道代码真实的执行情况、哪些代码未被覆盖。以此为基础,再去设计测试用例就会更有针对性了。

这里对工具暂时仅做了解即可。

 

总结:

感谢每一个认真阅读我文章的人!!!

作为一位过来人也是希望大家少走一些弯路,如果你不想再体验一次学习时找不到资料,没人解答问题,坚持几天便放弃的感受的话,在这里我给大家分享一些自动化测试的学习资源,希望能给你前进的路上带来帮助。

软件测试面试文档

我们学习必然是为了找到高薪的工作,下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料,并且有字节大佬给出了权威的解答,刷完这一套面试资料相信大家都能找到满意的工作。

 

          视频文档获取方式:
这份文档和视频资料,对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!以上均可以分享,点下方进群即可自行领取。

  • 21
    点赞
  • 22
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
测试的主要评测方法 简介   测试的主要评测方法包括覆盖和质量。   测试覆盖是对测试完全程度的评测,它建立在测试覆盖基础上,测试覆盖是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。   质量是对测试对象(系统或测试的应用程序)的可靠性、稳定性以及性能的评测。质量建立在对测试结果的评估和对测试过程中确定的变更请求(缺陷)的分析的基础上。 覆盖评测   覆盖指标提供了"测试的完全程度如何?"这一问题的答案。最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖。简而言之,测试覆盖是就需求(基于需求的)或代码的设计/实施标准(基于代码的)而言的完全程度的任意评测,如用例的核实(基于需求的)或所有代码行的执行(基于代码的)。   系统的测试活动建立在至少一个测试覆盖策略基础上。覆盖策略陈述测试的一般目的,指导测试用例的设计。覆盖策略的陈述可以简单到只说明核实所有性能。   如果需求已经完全分类,则基于需求的覆盖策略可能足以生成测试完全程度的可计量评测。例如,如果已经确定了所有性能测试需求,则可以引用测试结果来得到评测,如已经核实了 75% 的性能测试需求。   如果应用基于代码的覆盖,则测试策略是根据测试已经执行的源代码的多少来表示的。这种测试覆盖策略类型对于安全至上的系统来说非常重要。   两种评测都可以手工得到(公式如下所示)或通过测试自动化工具计算得到。 基于需求的测试覆盖   基于需求的测试覆盖在测试生命周期中要评测多次,并在测试生命周期的里程碑处提供测试覆盖的标识(如已计划的、已实施的、已执行的和成功的测试覆盖)。   在执行测试活动中,使用两个测试覆盖评测,一个确定通过执行测试获得的测试覆盖,另一个确定成功的测试覆盖(即执行时未出现失败的测试,如没有出现缺陷或意外结果的测试)。   这些覆盖评测通过以下公式计算:   这一关于测试覆盖的陈述是有意义的,可以将其与已定义的成功标准进行对比。如果不符合该标准,则此陈述将成为预测剩余测试工作量的基础。 基于代码的测试覆盖   基于代码的测试覆盖评测测试过程中已经执行的代码的多少,与之相对的是要执行的剩余代码的多少。代码覆盖可以建立在控制流(语句、分支或路径)或数据流的基础上。控制流覆盖的目的是测试代码行、分支条件、代码中的路径或软件控制流的其他元素。数据流覆盖的目的是通过软件操作测试数据状态是否有效,例如,数据元素在使用之前是否已作定义。   基于代码的测试覆盖通过以下公式计算: 质量评测   测试覆盖的评估提供对测试完全程度的评测,在测试过程中已发现缺陷的评估提供了最佳的软件质量指标。因为质量是软件与需求相符程度的指标,所以在这种环境中,缺陷被标识为一种更改请求,该更改请求中的测试对象与需求不符。   缺陷评估可能建立在各种方法上,这些方法种类繁多,从简单的缺陷计数到严格的统计建模不一而足。   严格的评估假定测试过程中缺陷达到的比率或发现的比率。常用模型假定该比率符合泊松分布。则有关缺陷率的实际数据可以适用于这一模型。生成的评估将评估当前软件的可靠性,并且预测继续测试并排除缺陷时可靠性如何增长。该评估被描述为软件可靠性增长建模,这是一个活跃的研究领域。由于该类型的评估缺乏工具支持,所以应该慎重平衡成本与其增加价值。   缺陷分析就是分析缺陷在与缺陷关联关系的一个或多个参数值上的分布。缺陷分析提供了一个软件可靠性指标。   对于缺陷分析,常用的主要缺陷参数有四个:   • 状态:缺陷的当前状态(打开的、正在修复或关闭的等)。   • 优先级:必须处理和解决缺陷的相对重要性。   • 严重性:缺陷的相关影响。对最终用户、组织或第三方的影响等等。   • 起源:导致缺陷的起源故障及其位置,或排除该缺陷需要修复的构件。   可以将缺陷计数作为时间的函数来报告,即创建缺陷趋势图或报告;也可以将缺陷计数作为一个或多个缺陷参数的函数来报告,如作为缺陷密度报告中采用的严重性或状态参数的函数。这些分析类型分别为揭示软件可靠性的缺陷趋势或缺陷分布提供了判断依据。   例如,预期缺陷发现率将随着测试进度和修复进度而最终减少。可以设定一个阈值,在缺陷发现率低于该阈值时才能部署软件。也可根据执行模型中的起源报告缺陷计数,以允许检测"较差的模块"、"热点"或需要再三修复的软件部分,从而指示一些更基本的设计缺陷。   这种分析中包含的缺陷必须是已确认的缺陷。不是所有已报告的缺陷都报告实际的缺陷,这是因为某些缺陷可能是扩展请求,超出了项目的规模,或描述的是已报告的缺陷。然而,需要查看并分析一下,为什么许多报告的缺陷不是重复的缺陷就是未经确认的缺陷,这样做是有价值的。 缺陷报告   Rational Unified Process 以三类形式的报告提供缺陷

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值