测试覆盖率之一——测试覆盖率分类(转)

本文介绍了测试覆盖率的概念,包括需求覆盖率和代码覆盖率,其中代码覆盖率细分为语句覆盖率、分支覆盖率和条件覆盖率。文章强调了100%覆盖率并不代表完全测试,并指出测试覆盖率在软件开发过程中的重要性,尤其是在持续集成中。测试覆盖率工具如JSCoverage、EMMA、Cobertura等也被提及。
摘要由CSDN通过智能技术生成

转一篇,别人写的关于覆盖率的文章,没事常看看琢磨琢磨

测试覆盖率之一——测试覆盖率分类(转)

关于覆盖率,网络上最常见的两个词应该是“测试覆盖率”(Test Coverage)和”代码覆盖率“(Code Coverage)。今天就来探探这两个东西。

在测试里面,一般会将测试覆盖率分为两个部分,即”需求覆盖率“和”代码覆盖率“。可以看到,代码覆盖率其实是测试覆盖率的一部分而已。其中,最常讨论和关心的是”代码覆盖率“,代码覆盖率又分为程序语句和代码行覆盖,分支覆盖和条件覆盖。对于这些概念,我们逐个解释。

需求覆盖率:如果需求已经定义好,这个时侯我们就需要考虑需求覆盖率了。这个时候需要注意的是,这里的需求不仅仅是指功能需求,还要包括性能需求。衡量需求覆盖率的最直观的方式是我们有多少功能点,我们有多少性能点要求,这些将作为分母;我们写了多少测试用例,覆盖了多少模块,多少功能点,我们的性能测试用例考虑了待测程序多少性能点,这些作为分子。

代码覆盖率:为了更加全面的覆盖,我们可能还需要测试程序的流程,我们可能会考虑到一个函数的数据的输入与输出,甚至是每一行代码的执行情况,代码的每一条逻辑和分支,这个时候我们的测试执行情况就以代码覆盖率来衡量,这也是我们常在单元测试中念叨的覆盖率覆盖率的问题。

语句覆盖率:换个名字叫做代码行覆盖率,这就是监视每行代码是否在用例(当然之所有的)中是否被执行到,准确点说是我们的用例里面大概执行了百分之多少的语句/代码行数。需要注意的是,即使所有的语句都被执行到,也不一定执行到了所有的路径。比如有五条语句:ABCDE,如果我们执行了用例覆盖了ABCDE,另外一个用例这个时候我们覆盖了所有语句,但是可能还存在一个路径(如ABC)没有执行,例如:

  public verifyToken(string yourname, string yourtitle)

  {

  A   output(”Hello, my dear friends“);

  B   if(yourname == "uniquestudiowcd")

  {

  C      output("Hello, Aaron");

  }

  D   if(yourtitle == "tester")

  {

  E     output("Hello, my dear tester");

  }

  }  

这个时候我们输入参数”uniquestudiowcd“和”tester“覆盖到了所有的语句,但是我们漏掉了一个路径:即输入参数”uniquestudiowcd“和”coder“。

分支覆盖率:我们也给它换个名字即”路径覆盖率“,尽管并不完全对。在上面的例子中,如果我们仅考虑了第一个用例(即输入参数”uniquestudiowcd“和”tester“),我们的语句覆盖率为100%,带式路径覆盖率可就低了,因为它存在ABD,ABCD,ABCDE,ABDE等等很多路径。

条件覆盖率:这也就是为什么不能说”分支覆盖“不同于”路径覆盖“的原因所在。如果我们在一个IF语句中加入了判断组合,那就要考虑更多的问题了,因为主要出现在条件语句中,所以我们称之为”条件覆盖“。我们更改上述示例代码:

  public verifyToken(string yourname, string yourtitle,string gendar)

  {

  A   output(”Hello, my dear friends“);

  B   if(yourname == "uniquestudiowcd" && gendar == ”man“)

  {

  C      output("

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值