精华内容
下载资源
问答
  • 代码覆盖率

    2020-04-07 17:44:06
    代码覆盖率代码覆盖率简介覆盖率工具 代码覆盖率简介 作为一个测试人员,保证产品的软件质量是其工作的首要目标。为了这个目标,测试人员常常会通过很多手段或工具来加以保证,覆盖率就是其中比较重要的一个。我们...

    代码覆盖率简介

    作为一个测试人员,保证产品的软件质量是其工作的首要目标。为了这个目标,测试人员常常会通过很多手段或工具来加以保证,覆盖率就是其中比较重要的一个。我们通常会将测试覆盖率分为两个部分,即“需求覆盖率”和“代码覆盖率”。需求覆盖率:指测试人员对需求的了解程度,根据需求的可测试性拆分成各个子需求点,来编写相应的测试用例,最终建立一个需求和用例的映射关系,以用例的测试结果来验证需求的实现,可以理解为黑盒覆盖。代码覆盖率:为了更加全面地覆盖,我们可能还需要理解被测程序的逻辑,需要考虑到每个函数的输入与输出、逻辑分支代码的执行情况,这个时候我们的测试执行情况就以代码覆盖率来衡量,可以理解为白盒覆盖。以上两者完全可以相辅相成,用代码覆盖结果反向地检验需求覆盖(用例)的测试是否充分完整。

    覆盖率工具

    1.Javascript测试覆盖率工具JSCoverage:一个用于度量Javascript程序的代码覆盖率的工具,JSCoverage支持IE6、IE7、Firefox2、Firefox3、Opera、Safari等流行的浏览器,支持Windows平台和Linux平台,JSCoverage是开源软件,官方网站为:http://siliconforks.com/jscoverage/。

    2.Java测试覆盖率工具

    Emma:离线插桩模式,即先编译出class文件,然后插桩,打包运行。不支持分支覆盖率,其使用手册地址为:http://emma.sourceforge.net/reference_single/reference.html。

    JaCoCo:特色是引入agent,支持在线插桩模式,即在class加载的时候即时插桩,同时也支持离线插桩,具有丰富的dump机制,支持分支覆盖率,运行速度比较快。其使用地址为:http://eclemma.org/JaCoCo/index.html。支持gradle方式,我们在Android覆盖率方面选用的工具为JaCoCo,优势主要集中在两点:一是JaCoCo社区比较活跃,它是原Emma团队新推出的覆盖率工具,Emma项目已经很久没有更新了;二是JaCoCo比Emma多了分支覆盖。

    Coverlipse:一个Eclipse的Code coverage插件。

    Cobertura:一种开源工具,它通过检测基本的代码,并观察在测试包运行时执行了哪些代码和没有执行哪些代码,来测量测试覆盖率。除了找出未测试到的代码并发现bug外,Cobertura还可以通过标记无用的、执行不到的代码来优化代码,还可以提供API实际操作的内部信息。

    3..NET测试覆盖率工具

    Clover.NET:Visual Studio的代码覆盖率统计工具,其官方网站为:http://www.cenqua.com/clover.net/。

    NCover官方网站为:http://ncover.org/。

    PartCover:与NCover非常相似,PartCover是针对.NET的一个开源代码覆盖工具。它包括了一个控制台应用程序、GUI覆盖浏览器,以及用在CC.NET中的xsl转换。

    4.C/C++测试覆盖率工具

    Bullseye Coverage:Bullseye公司提供的一款C/C++代码覆盖率测试工具,除了支持各种UNIX下的编译器之外,在Windows下还支持VC、Borland C++、Gnu C++、Inter C++。提供的代码覆盖率是分支覆盖率而不是一般的代码覆盖率,个人认为分支覆盖率比代码覆盖率更好。Bullseye Coverage可以从http://www.bullseye.com/上获取。

    5.Ruby测试覆盖率工具

    rcov:一个用于诊断Ruby代码覆盖率的工具,它最主要的用途就是确定单元测试是否覆盖到所有代码,rcov使用一个经过优化的C运行,因此性能相当惊人,同时它还提供多种格式的输出。

    6.其他
    AutomatedQA公司的AQtime。AQtime运行在Windows平台上,它支持.NET应用和非.NET应用,但不支持Java应用。AQtime除了包含代码覆盖率监测以外,还包括性能监视等功能。DevPartner Studio的Web script Coverage工具。该工具主要是收集Web客户端script脚本覆盖率的。

    展开全文
  • 代码覆盖率和测试覆盖率 测试覆盖率和代码覆盖率是衡量代码有效性的最流行方法。 尽管这些术语有时会互换使用,因为它们的基本原理相同。 但是它们并不像您想象的那样相似。 很多时候,我注意到测试团队和开发团队...

    代码覆盖率和测试覆盖率

    测试覆盖率和代码覆盖率是衡量代码有效性的最流行方法。 尽管这些术语有时会互换使用,因为它们的基本原理相同。 但是它们并不像您想象的那样相似。 很多时候,我注意到测试团队和开发团队对这两个术语的使用感到困惑。 这就是为什么我想到写一篇文章来详细讨论代码覆盖率和测试覆盖率之间的区别的原因。

    代码覆盖率与测试覆盖率:它们有何不同?

    代码覆盖率:指示通过用Selenium或任何其他测试自动化框架进行的手动测试和自动化测试,测试用例覆盖的代码百分比。 例如,如果您的源代码具有一个简单的if ... else循环,则如果您的测试代码将覆盖这两种情况(即if&else),则代码覆盖率将为100%。

    测试范围:包括测试作为功能需求规范,软件需求规范和其他必需文档的一部分而实现的功能。 例如,如果要对Web应用程序执行跨浏览器测试 ,以确保您的应用程序是否可以从其他浏览器很好地呈现? 您的测试范围将围绕验证了Web应用程序的浏览器兼容性的浏览器+操作系统组合的数量。

    了解了代码覆盖率和测试覆盖率之间的基本区别之后,让我们跳入有关代码覆盖率和测试覆盖率的更多详细信息。

    深入了解代码覆盖率

    开发人员在单元测试期间执行代码覆盖,以验证代码实现,从而几乎执行所有代码语句。 大多数代码覆盖率工具都使用静态工具,将监视执行的语句插入到代码中的必要位置。 尽管添加检测代码会导致整体应用程序大小和执行时间增加,但与通过执行检测代码生成的信息相比,开销却很小。 输出包括一个详细描述测试套件测试范围的报告。

    为什么要执行代码覆盖率?

    单元测试主要用于在单个单元级别上测试代码。 由于单元测试由开发人员自己编写,因此他对应该作为单元测试的一部分包含的测试具有更好的可见性。 单元测试有助于提高软件的整体质量,但是始终存在关于组成单元测试的测试数量的问题。 测试套件中是否有足够数量的测试方案? 我们应该添加更多测试吗? 代码覆盖率是所有这些问题的答案。

    随着产品开发的进行,新功能以及修复程序(针对测试过程中产生的错误)将添加到发布周期中。 这意味着测试代码可能还需要更改,以便通过开发过程中进行的软件更改来保持更新。 在项目开始时设定的测试标准必须与后续的发布周期保持一致,这一点很重要。 代码覆盖率可用于确保您的测试符合这些标准,并且质量最好的代码进入生产阶段。

    代码覆盖率更高; 出现未检测到的错误的机会越低。 在某些组织中,质量团队设置在将软件推向生产阶段之前需要实现的最小代码覆盖量。 这样做的主要原因是为了减少在产品开发的后期发现错误的可能性。

    如何执行代码覆盖率?

    代码覆盖范围有不同的级别,代码覆盖率的一些常见子类型为:

    • 分支机构覆盖范围–分支机构覆盖范围也称为决策覆盖范围,用于确保决策过程中使用的每个可能的分支都得以执行。 例如,如果您使用代码中的If…Ans条件语句或Do…While语句合并后备跨浏览器兼容性,作为覆盖范围的一部分; 您必须通过提供适当的输入以使跨浏览器兼容的网站来确保对所有分支(即If,Else,Do和While)进行测试。
    • 功能覆盖范围–功能覆盖范围可确保测试必要的功能(尤其是导出的功能/ API)。 这还应包括使用不同类型的输入参数测试功能,因为这也将测试功能中使用的逻辑。 一旦测试了代码中的所有功能,功能覆盖率将为100%。
    • 语句覆盖率–这是一种重要的代码覆盖率方法,其中必须以某种方式编写测试代码,即源代码中的每个可执行语句至少执行一次。 这也包括极端情况或边界情况。
    • 循环覆盖–这种方法是确保源中的每个循环至少执行一次。 可能会根据您在运行时获得的结果来执行某些循环,同样重要的是测试此类循环以使代码万无一失。

    为了检查代码覆盖率,使用了一种称为检测的方法。 工具可用于监视性能,插入跟踪信息以及诊断源代码中的任何类型的错误。 仪器种类繁多,取决于所使用的仪器方法,可能会有最小的性能(和时序)开销。

    仪器类型

    仪器分为三种主要类型

    • 代码检测-这里的源代码是在添加检测语句之后编译的。 编译应使用常规工具链完成,编译成功将导致生成检测装配。 例如,为了检查在代码中执行特定功能所花费的时间,可以在功能的“开始”和“结束”中添加检测语句。
    • 运行时检测–与代码检测方法相反,此处的信息是从运行时环境(即在执行代码时)收集的。
    • 中间代码检测–在这种检测中,通过向已编译的类文件中添加字节码来生成检测类。

    根据测试要求,您应该选择正确的代码覆盖率工具以及该工具支持的最佳检测方法。

    代码覆盖率工具

    有许多支持不同编程语言的代码覆盖工具,其中许多还可以兼用作QA工具。 许多工具可以与构建工具和项目管理工具集成在一起,从而使它们更加强大和有用。 选择开源代码覆盖率工具时,应检查该工具支持的功能以及该工具是否正在积极开发中。 基于这些因素,以下是一些流行的开源代码覆盖工具。

    1. Coverage.py –这是Python的代码覆盖工具。 顾名思义,它可以分析您的源代码并确定已执行代码的百分比。 它是用Python开发的。 它是免费的,您可以参考https://coverage.readthedocs.io/en/coverage-5.0.3/了解更多信息。
    2. Serenity BDD –支持Java和Groovy编程语言,Serenity BDD是一个流行的开源库,主要用于更快地编写出色的质量验收测试。 您可以使用故事和史诗进行测试,并为这些故事和史诗计算代码覆盖率。 因此,生成的测试报告实际上更具说明性和叙述性。 您可以将这些自动化测试映射回您的需求中。
      它可以与JUnit,Cucumber和JBehave一起使用。 Serenity BDD可以轻松地与Maven,Cradle,JIRA和Ant集成。 如果您使用Selenium WebDriver或Selenium Grid框架进行自动化测试,则选择Serenity BDD将具有巨大优势,因为它与Selenium兼容。 您可以参考https://www.thucydides.info/#/documentation了解更多信息。
    3. JaCoCo – JaCoco是Java的代码覆盖工具。 尽管还有其他选项,例如Cobertura和EMMA,但由于长时间没有更新,因此不推荐使用这些工具。 JaCoCo工具是Eclipse Foundation的一部分,它替代了Eclipse中的EMMA代码覆盖率工具。 除了积极开发JaCoCo之外,使用JaCoCo的另一个优势是可以与CI / CD和项目管理工具(例如Maven,Jenkins,Gradle等)无缝集成。请访问官方网站以获取更多信息。
    4. JCov – JCov是测试框架不可知代码覆盖工具。 它可以轻松地与Oracle的测试基础架构JavaTest和JTReg集成。 尽管尚未积极开发,但对即时检测和脱机检测的支持是使用JCov的主要优势。 请访问https://wiki.openjdk.java.net/display/CodeTools/jcov了解更多信息。
    5. PITest –大多数代码覆盖率工具都会检查代码的分支覆盖率,语句覆盖率,循环覆盖率等,并给出覆盖率结果。 尽管这些信息对于提高测试代码的质量很有用,但是测试并不能告诉您自动化测试在发现错误方面的表现如何。 这是变异测试非常有用的地方。
      PITest是一种非常流行的代码覆盖工具,用于Java和JVM的变异测试。 它通过修改您的测试代码来完成变异测试的工作,并且现在在此修改后的代码上执行单元测试。 如果使用此代码发现了错误,即PITest添加了额外的代码后,则单元测试是万无一失的。 否则,由于尚未发现问题,因此需要更改。 PITest易于使用,快速且正在积极开发中。 它还与流行的CI / CD工具集成在一起,使其更加有用。 有关更多信息,请访问http://pitest.org/

    深入了解测试覆盖率

    与代码覆盖率是白盒测试方法不同,测试覆盖率是黑盒测试方法。 以最大范围覆盖FRS(功能需求规范),SRS(软件需求规范),URS(用户需求规范)等中提到的需求的方式编写测试用例。由于测试是从这些文档中衍生的,因此自动化的机会很小/没有机会。

    如何执行测试覆盖率?

    与代码覆盖率一样,也可以通过不同类型的测试来评估测试覆盖率。 但是,应遵循哪种测试完全取决于您的业务主张。例如–在以用户为中心的Web应用程序中,可能会出现UI / UX测试比功能测试具有更高优先级的情况,而在其他类型的应用程序中(例如银行,金融); 可用性测试,安全性测试等可能更为重要。

    以下是一些测试覆盖率机制:

    • 单元测试–这种测试在单元级别/模块级别执行。 在单元级别遇到的错误可能与在集成阶段遇到的问题不同。
    • 功能测试–在功能测试中,将根据功能需求规范(FRS)中提到的要求对功能/功能进行测试。
    • 集成测试–由于软件是在系统级别进行测试的,因此也称为系统测试。 一旦集成了所有必需的模块,便会执行此类测试。
    • 验收测试–全部取决于验收测试的结果,是否将产品发布给最终消费者/客户。 在此,开发人员可以从Web应用程序的测试人员和SME获得绿色通道的批准,然后才将代码更改从暂存环境推送到生产环境

    要注意的另一个重要点是,测试覆盖范围的目的和含义可能会根据执行测试的级别而有所不同。 它还取决于执行黑盒测试的产品类型。 用于测试手机的测试覆盖率指标将不同于用于电子商务网站测试的指标。 一些分类如下:

    • 功能覆盖范围–在此情况下,以最大程度覆盖产品功能的方式开发测试用例。 例如,如果为测试人员分配了测试电话拨号程序应用程序的工作, 他应确保所拨打的号码长度正确。 如果测试是在印度完成的,则手机号码最多为10位数字; 否则它应该闪烁一个错误。 与此类似,必须根据产品团队设置的优先级对所有必需和可选功能进行测试。
    • 风险范围–每个产品/项目需求文档都有一节提到与项目相关的风险和缓解措施。 尽管某些风险(例如,业务动态的变化)超出了计划/开发/测试团队的范围,但在测试阶段仍需要解决一些风险。
      例如,在开发商业网站时,应该以非常快速的页面访问方式来设置服务器基础结构。 根据访问网站的位置(即国家,城市等),应选择最接近的服务器来加载网站。 否则,整个体验将受到阻碍。 测试团队还应该执行负载测试,其中当多个用户尝试同时访问该网站时即完成性能测试时,即网站上流量巨大的场景。 如果这些测试的结果不好,则可能会导致用户体验低于平均水平(这可能会带来巨大的风险)。
    • 需求范围–这里定义测试的方式是最大程度地覆盖各种需求规范文档中提到的产品需求。
      例如,如果您正在测试预安装的SMS应用程序,则需要确保正确设置默认语言,例如,如果手机在英语不是主要语言的国家/地区销售,例如中国; 默认的SMS语言应为中文,并适用于其他客户(例如印度); 默认语言应为英语。

    测试覆盖率工具

    在代码覆盖率的情况下,度量标准是通过测试用例/测试套件测试的代码的百分比。 因此,可以量化测试结果,即在100 LOC(代码行)中,代码覆盖率为80行。 这意味着代码覆盖率为80%。 由于执行测试以验证功能要求,因此无法量化测试覆盖率的结果。 您还可以提出可以在单个测试中测试多个需求的黑盒测试,例如,为了在简单的电子邮件登录页面中测试失败情况,您可以编写一个测试用例,输入不带@的电子邮件地址符号,然后尝试继续登录。 这将测试登录页面的功能,并检查用于验证电子邮件地址格式的逻辑是否按要求工作。

    尽管在少数情况下必须编写测试代码来达到测试覆盖率要求,但是在某些情况下,您可能仍需要使用一些流行的测试框架。 两种最受欢迎​​的测试框架是:

    • JUnit – JUnit是Java的单元测试框架。 它也可以用于UI测试。 它是开源的,并且在TDD(测试驱动开发)的开发中被认为很重要。 开发人员和测试人员使用JUnit编写和执行重复的测试。 这也使它成为回归测试的流行框架。 有关更多信息,请参阅https://junit.org/junit5/

    使用JUnit首先运行Selenium Automation测试脚本

    • PyUnit – PyUnit(也称为Python单元测试框架)是一种广泛用于单元测试的广泛使用的测试框架。 它是JUnit的Python端口,由遵循TDD方法的Python开发人员使用。 PyUnit支持测试用例,测试套件,测试装置等的开发。unittest模块是PyUnit框架的核心。 请参阅https://docs.python.org/2/library/unittest.html了解更多信息。

    使用PyUnit首先运行Selenium自动化测试脚本

    尽管开发人员/测试人员可以使用许多其他工具/测试框架来编写测试代码,但JUnit和PyUnit是各自编程语言中最受欢迎的测试框架。

    您应该遵循哪一个?

    衡量代码覆盖率和测试覆盖率的影响的基础完全不同。 代码覆盖率是通过测试期间覆盖的代码百分比来衡量的,而测试覆盖率是通过测试覆盖的功能来衡量的。

    百万美元的问题是“其中哪一项最适合您的项目”? 这个问题没有明确的答案,因为解决方案取决于项目的类型和复杂性。 在大多数情况下,使用测试覆盖率和代码覆盖率,因为它们在软件项目中同等重要。

    测试覆盖范围的优势

    • 一种测试软件功能并比较不同规范文档(需求,功能,产品,UI / UX等)结果的好方法
    • 由于作为覆盖范围一部分执行的测试实际上是黑盒,因此执行这些测试可能不需要太多的专业知识。

    取决于测试覆盖范围的缺点

    • 由于测试主要是黑盒测试,因此没有自动化范围。 测试结果的手动比较必须与预期的输出进行,因为这些测试是在“功能级别”而不是“代码级别”执行的。
    • 没有测量测试覆盖率的具体方法。 因此,覆盖范围的结果在很大程度上取决于正在执行测试的测试人员的领域能力,并且可能因一个测试人员而异。

    代码覆盖范围的优势

    • 提供测试代码的有效性以及如何提高覆盖率
    • 无论使用哪种工具(开源,高级),设置代码覆盖率工具都不会花费很多时间。
    • 通过捕获代码中的错误来帮助提高代码质量。

    代码覆盖范围的缺点

    • 大多数代码覆盖率工具仅限于单元测试。
    • 因此,工具使用的方法可能有所不同; 您可能无法将一种工具的代码覆盖率结果与另一种工具进行比较。
    • 搜索最适合的工具可能是一项艰巨的任务,因为在选择最适合您项目需求的工具之前,您需要比较并尝试这些工具的功能。
    • 提供很少支持不同编程语言(例如Java,Python,C等)的工具。因此,如果您的团队使用多种编程语言(用于测试代码开发),则可能需要多个工具。

    多少覆盖范围足够?

    测试次数更多; 产品的质量越好。 设计,开发和测试团队之间应该经常沟通,以便每个利益相关者都可以了解有关项目活动的详细信息。

    测试团队应花费大量时间来了解总体要求并确定测试活动的优先级。 为了跟踪进度,他们应该有一个清单,该清单应该定期更新(至少在每个发行版之后)。 测试团队还必须与质量保证(QA)团队保持频繁的沟通,这是很重要的,因为他们拥有要发布给客户/客户的产品/项目必须达到的目标(测试/代码)覆盖范围的详细信息。

    总而言之,没有专门的经验法则提到测试产品时需要达到的最小代码覆盖率或测试覆盖率百分比。

    如何确保最大的代码覆盖率和测试覆盖率?

    通过测试获得更好结果的一种方法是将自动化纳入测试计划。 不可能完全自动化整个测试过程,因此您必须制定一个计划。 该计划应突出显示必须手动和通过自动化执行的测试活动。

    覆盖率是一个有用的指标,但范围有限。 没有理想的方法可以衡量在测试上花费的精力。 众所周知的事实是100%的覆盖率只是一个神话。

    包含不同类型的测试(例如自动化测试,集成测试,手动测试,跨浏览器测试等)的整体方法将非常有用。 它可以帮助您在一个地方衡量不同测试和测试系统的有效性。

    不要针对100%的代码覆盖率

    您要记录的一件事是,永远不要以为100%的代码覆盖率都认为您的代码更改没有错误。 原因是100%的代码覆盖率表示您的自动化测试脚本覆盖了每一行代码。 但是,我们需要考虑错误的否定和错误的肯定,这可能会使我们脱离所添加代码的现实。 另外,您的Web应用程序中还会有一些未经测试的代码。 您需要仔细考虑未经测试的代码。 如果它是从旧版本中删除的,则可以将其删除;或者,如果它是来自缺少文档的最新修补程序,则对其进行测试。

    结论

    代码覆盖率是白盒方法,而测试覆盖率是黑盒测试方法。 根据项目的要求和范围,您应该选择测试覆盖率/代码覆盖率/测试覆盖率和代码覆盖率。 您应该确定测试活动的优先级,并为每个活动指定一个暂定期限。 不管使用哪种方法,重要的是要达到更高的覆盖率,因为这将表明代码和产品功能已得到很好的测试。 干杯!

    翻译自: https://www.javacodegeeks.com/2020/02/code-coverage-vs-test-coverage-which-is-better.html

    代码覆盖率和测试覆盖率

    展开全文
  • 覆盖率验证——代码覆盖率+功能覆盖率

    千次阅读 多人点赞 2020-04-25 14:52:32
    文章目录一、基于覆盖率驱动的验证技术二、代码覆盖率功能覆盖率三、功能覆盖率建模3.1.功能覆盖率模型——covergroup3.2.覆盖点——coverpoint3.3.覆盖点的——bins四、代码code 一、基于覆盖率驱动的验证技术 采用...

    一、基于覆盖率驱动的验证技术

       采用覆盖率驱动的验证方式可以量化验证进度,保证验证的完备性。一般在验证计划中会指定具体的覆盖率目标。通过覆盖率验证可以确定验证是否达到要求。当然,达到目标覆盖率并不意味着验证就通过了,因为功能覆盖率是由人为定义的,有时候即便达到100%,也未必将所有的功能场景全部覆盖了,因为人为主观定义的功能场景有时候可能存在遗漏,所以还需要对测试用例进行迭代。

    二、代码覆盖率与功能覆盖率

    1. 代码覆盖率:工具会自动搜集已经编写好的代码,常见的代码覆盖率如下:
    • 行覆盖率(line coverage):记录程序的各行代码被执行的情况。
    • 条件覆盖率(condition coverage):记录各个条件中的逻辑操作数被覆盖的情况。
    • 跳转覆盖率(toggle coverage):记录单bit信号变量的值为0/1跳转情况,如从0到1,或者从1到0的跳转。
    • 分支覆盖率(branch coverage):又称路径覆盖率(path coverage),指在if,case,for,forever,while等语句中各个分支的执行情况。
    • 状态机覆盖率(FSM coverage):用来记录状态机的各种状态被进入的次数以及状态之间的跳转情况。
    1. 功能覆盖率:`是一种用户定义的度量,主要是衡量设计所实现的各项功能,是否按预想的行为执行,即是否符合设计说明书的功能点要求,功能覆盖率主要有两种如下所示:
    • 面向数据的覆盖率(Data-oriented Coverage)-对已进行的数据组合检查.我们可以通过编写覆盖组coverage groups)、覆盖点coverage points)和交叉覆盖cross coverage)获得面向数据的覆盖率.
    • 面向控制的覆盖率(Control-oriented Coverage)-检查行为序列sequences of behaviors)是否已经发生.通过编写SVA来获得断言覆盖率(assertion coverage).

    需要指出的是: 代码覆盖率达到要求并不意味着功能覆盖率也达到要求,二者无必然的联系。而为了保证验证的完备性,在收集覆盖率时,要求代码覆盖率和功能覆盖率同时达到要求。

    三、功能覆盖率建模

    功能覆盖率主要关注设计的输入、输出和内部状态,通常以如下方式描述信号的采样要求;

    • 对于输入,它检测数据端的输入和命令组合类型,以及控制信号与数据传输的组合情况。
    • 对于输出,它检测是否有完整的数据传输类别,以及各种情况的反馈时序。
    • 对于内部设计,需要检查的信号与验证计划中需要覆盖的功能点相对应。通过对信号的单一覆盖、交叉覆盖或时序覆盖来检查功能是否被触发,以及执行是否正确。

    3.1.覆盖组——covergroup

       使用覆盖组结构(covergroup)定义覆盖模型,覆盖组结构(covergroup construct)是一种用户自定义的结构类型,一旦被定义就可以创建多个实例就像类(class)一样,也是通过new()来创建实例的。覆盖组可以定义在module、program、interface以及class中。

    每一个覆盖组(covergroup)都必须明确一下内容:

    • 一个时钟事件以用来同步对覆盖点的采样;
    • 一组覆盖点(coverage points),也就是需要测试的变量
    • 覆盖点之间的交叉覆盖;
    • 可选的形式参数;
    • 覆盖率选项;
    covergroup cov_grp @(posedge clk);    //用时钟明确了覆盖点的采样时间,上升沿采样覆盖点,也可省略clk,在收集覆盖率时在根据情况注明
      cov_p1: coverpoint a;//定义覆盖点,cov_p1为覆盖点名,a为覆盖点中的变量名,也就是模块中的变量名
    endgroup
     
    cov_grp cov_inst = new();//实例化覆盖组
    

      上述例子用时钟明确了覆盖点的采样时间,上升沿采样覆盖点,也可省略clk,在收集覆盖率时在根据情况注明,如下示例:

    covergroup cov_grp;
      cov_p1: coverpoint a;//cov_p1为覆盖点名,a为覆盖点中的变量名,也就是模块中的变量名
    endgroup
     
    cov_grp cov_inst = new();
    cov_inst.sample();          //sample函数收集覆盖率
    

      上面的例子通过内建的sample()方法来触发覆盖点的采样.

    logic [7:0] address;
    covergroup address_cov (ref logic [7:0] address,        //添加形式参数
           input int low, int high) @ (posedge ce);
        ADDRESS : coverpoint address {
          bins low    = {0,low};
          bins med    = {low,high};
        }
      endgroup
     
    address_cov acov_low  = new(addr,0,10);
    address_cov acov_med  = new(addr,11,20);
    address_cov acov_high = new(addr,21,30);
    

       覆盖组中允许带形式参数,外部在引用覆盖组时可以通过传递参数,从而对该覆盖组进行复用。

    3.2.覆盖点——coverpoint

      一个覆盖组可以包含多个覆盖点,每个覆盖点有一组显式bins值,bins值可由用户自己定义,每个bins值与采样的变量或者变量的转换有关。一个覆盖点可以是一个整型变量也可以是一个整型表达式。覆盖点为整形表达式的示例如下:注意覆盖点表达式写法。

    class Transaction();
       rand bit[2:0]  hdr_len;       //取值:0~7
       rand bit[3:0]  payload_len;   //取值:0~15
       ...
    endclass
    
    Transaction   tr;
    
    covergroup Cov;
       len16: coverpoint(tr.hdr_len + tr.payload_len);    //注:取值范围为0~15
       len32:coverpoint(tr.hdr_len + tr.payload_len + 5'b0);   //注:取值范围为0~31
    endgroup
    

      当进行仿真后,len16的覆盖点覆盖率最高可达100%,而覆盖点len32的覆盖率最高只能达到23/32=71.87%。由于总的bins数量为32个,而实际最多只能产生产生len_0,len_1,len2,…,len22共23个bins,所以覆盖率永远不可能达到100%。

      如果要使覆盖点len32达到100%的覆盖率,可以手动添加自定义bins,代码如下:

    covergroup Cov;
       len32:coverpoint(tr.hdr_len + tr.payload_len + 5'b0);   //注:取值范围为0~31  
                        {bins  len[] = {[0:22]};} 
    

      此时将覆盖点的范围限定在0~22之间,符合覆盖点的实际取值范围,故覆盖率可以达到100%。

    3.3.覆盖点元素——隐式bin与显式bins

    • 隐式或自动bin:覆盖点变量,其取值范围内的每一个值都会有一个对应的bin,这种称为自动或隐式的bin。例如,对于一个位宽为nbit的覆盖点变量,若不指定bin个数,2^n个bin将会由系统自动创建,需要注意的是 自动创建bin的最大数目由auto_bin_max内置参数决定,默认值64
    program automatic test(busifc.TB ifc);        //接口例化
       class Transaction;
          rand bit [3:0]  data;
          rand bit [2:0]  port;
       endclass
    
       covergroup Cov;           //定义覆盖组,未添加时钟信号,此时需要使用sample()函数采集覆盖率
          coverpoint  tr.port;     //设置覆盖点
       endgroup
    
       initial begin
          Transaction  tr=new();     //例化数据包
          Cov          ck=new();     //例化覆盖组
          repeat(32) begin
             tr.randomize();
             ifc.cb.port <= tr.port;
             ifc.cb.data <= tr.data;
             ck.sample();            //采集覆盖率
             @ifc.cb;
          end
       end
       
    endprogram   
    

    对于覆盖点tr.port,如果覆盖率达到100%,那么将会有auto[0],auto[1],auto[2] … auto[7]等8个bin被自动创建。其实际功能覆盖率报告如下:
    在这里插入图片描述

    • 显式bins:"bins"关键字被用来显示定义一个变量的bin,用户自定义bin可以增加覆盖的准确度,它属于功能覆盖率的一个衡量单位。在每次采样结束时,生成的数据库中会包含采样后的所有bins,显示其收集到的具体覆盖率值。最终的覆盖率等于采样的bins值除以总的bins值。
    covergroup 覆盖组名 @(posedge clk);//时钟可以没有
      覆盖点名1: coverpoint 变量名1{ bins bin名1 = {覆盖点取值范围}(iff(expression));  //iff结构可以指定采样条件
                                    bins bin名2 = {覆盖点取值范围};
                                    bins bin名3 = {覆盖点取值范围};
                                  .......
                                  }//一般会将bin的数目限制在8或16
                               。。。。。。
    endgroup : 覆盖组名
    
    iff结构的运用实例如下:
    bit[1:0]  s0;
    covergroup  g4;
      cover1: coverpoint s0 iff(!reset) ;    //当reset=0时,表达式为真开始采样 
    endgroup
     
    //注意对coverpoint的bin的声明使用的是{},这是因为bin是声明语句而非程序语句,而且{}后也没有加分号
    

      针对某一变量,我们关心的可能只是某些区域的值或者跳转点,因此我们可以在显示定义的bins中指定一组数值(如3,5,6)或者跳转序列(如3->5->6) 显示定义bins时,可通过关键字default将未分配到的数值进行分配

    covergroup  Cov;
       coverpoint  tr.data{             //data变量的取值范围为0~15,不设置显示bins时,理论上会有16个bin
                   bins  zero = {0};            //取值:0
                   bins  lo = {[1:3],5};        //取值:1,2,3,5
                   bins  hi[] = {[8:$]};        //取值:8~15,使用动态数组方法时相当于创建了hi[0],hi[1],...,hi[7]一共8个bins
                   bins  misc = default;        //余下的所有值:4,6,7
       }
    

    其部分覆盖率报告如下:
    在这里插入图片描述
      除了在bins中定义数值,还可以定义数值之间的跳转,操作符(=>),如下所示:

    bit[2:0]     v;
    covergroup  sg@(posedge clk);
       coverpoint  v{bins b2=(3 => 4 => 5);   //3 to 5
                     bins b3=(1,5 => 6=>7);   //(1=>6)、(1=>7)、(5=>6)、(5=>7)
                     bins b5=(5[*3]);         //3 consecutive 5's(连续重复,数值5的3次重复连续)
                     bins b6=(3[*3:5]);       //(3=>3=>3)、(3=>3=>3=>3)、(3=>3=>3=>3=>3)
                     bins b7=(4[->3]=>5);     //...=>4...=>4...=>4=>5(跟随重复,4出现3次,可以不连续,但在最后一个4出现后,下一个数值为5)
                     bins b8=(2[=3]=>5);      //...=>2...=>2...=>2...=>5(非连续重复,数值2出现3次)
                     bins anothers=default_sequence;
                     }
    endgroup
    

    3.4.覆盖点之间的交叉覆盖率——cross

      交叉覆盖是在覆盖点或变量之间指定的,必须先指定覆盖点,然后通过关键字cross定义覆盖点之间的交叉覆盖

    //通过覆盖点来定义交叉覆盖
    bit [3:0] a, b;
    covergroup cg @(posedge clk);
      c1: coverpoint a;
      c2: coverpoint b;
      c1Xc2: cross c1,c2;    //1. 定义交叉覆盖使用关键字cross,利用**覆盖点名字**定义交叉覆盖
    endgroup : cg
     
    //通过变量名来定义交叉覆盖
    bit [3:0] a, b;
    covergroup cov @(posedge clk);
      aXb : cross a, b;      //2. 定义交叉覆盖使用关键字cross,直接利用**变量名字**定义交叉覆盖
    endgroup
     
    //交叉覆盖的通用定义格式: 
    交叉覆盖名:cross 交叉覆盖点名1,交叉覆盖点名2;
    

       由于上面每个覆盖点都有16个bin,所以它们的交叉覆盖总共有256(16*16)个交叉积(cross product),也就对应256个bin

    bit [3:0] a, b, c;
    covergroup cov @(posedge clk);
      BC  : coverpoint b+c;
      aXb : cross a, BC;
    endgroup
    

    上例的交叉覆盖总共有256个交叉积(cross product),也对应256个bin.

    3.5.覆盖点之间的状态跳转

    3.6.覆盖率的选项与方法

    • at_least——覆盖阈值,定义一个bin在执行代码过程中至少触发的次数,低于这个触发次数的话,这个bin不算覆盖,默认值是1;
    • auto_bin_max——当没有bin为显示创建时,定义一个覆盖点的自动bin的最大数量,默认值为64;
    • cross_auto_bin_max——定义一个交叉覆盖的交叉积(cross product)的自动bin的最大数量,没有默认值;
    covergroup cg @(posedge clk);
      c1: coverpoint addr  { option.auto_bin_max = 128;}//addr自动bin的数目最大为128
      c2: coverpoint wr_rd { option.at_least = 2;}//wr_rd的每个bin至少要触发两次,否则不算覆盖
      c1Xc2: cross c1, c2  { option.cross_auto_bin_max = 128;}//交叉积的自动bin数目最大为128
    endgroup : cg
    
    //覆盖选项如果是在某个coverpoint中定义的,那么其作用范围仅限于该coverpoint;
    //如果是在covergroup中定义的,那么其作用范围是整个covergroup;
    

    四、代码code——约束与覆盖率的运用

    • void sample() : Triggers the sampling of covergroup 触发覆盖组的采样
    • real get_coverage() : Calculate coverage number, return value will be 0 to 100 返回覆盖组覆盖率
    • real get_inst_coverage() :Calculate coverage number for given instance, return value will be 0 to 100 返回覆盖组实例的覆盖率
    • void set_inst_name(string) :Set name of the instance with given string 设置实例名
    • void start() :Start collecting coverage 开启覆盖率收集
    • void stop() :Stop collecting coverage 结束收集覆盖率
    module test();
     
    logic [2:0] addr;
    wire [2:0] addr2;
     
    assign addr2 = addr + 1;
     
    covergroup address_cov;
      ADDRESS : coverpoint addr {
        option.auto_bin_max = 10;
      }
      ADDRESS2 : coverpoint addr2 {
        option.auto_bin_max = 10;
      }
    endgroup
     
    address_cov my_cov = new;
     
    initial begin
      my_cov.ADDRESS.option.at_least = 1;
      my_cov.ADDRESS2.option.at_least = 2;
      // start the coverage collection
      my_cov.start();
      // Set the coverage group name
      my_cov.set_inst_name("ASIC-WORLD");
      $monitor("addr 8'h%x addr2 8'h%x",addr,addr2);
      repeat (10) begin
        addr = $urandom_range(0,7);
        // Sample the covergroup
        my_cov.sample();
        #10;
      end
      // Stop the coverage collection
      my_cov.stop();
      // Display the coverage
      $display("Instance coverage is %e",my_cov.get_coverage());
    end
     
    endmodule
    

    4.1.通过修改随机化次数——提高覆盖率(覆盖点变量取值范围小)

    1)、在不添加约束constraint、不使用自定义bins,的情况下:

    module cov_demo();
    
      class transaction;
          rand bit[31:0]  data;        //2^32种可能
          rand bit[2:0]  port;         //0~7,一共8种可能
      endclass
        
       covergroup cov_port;
           port_bin : coverpoint tr.port;
           data_bin : coverpoint tr.data;
       endgroup
         
        transaction    tr=new;      //声明类的句柄,创建对象
        cov_port       ck=new;      //声明覆盖组的句柄,创建对象; covergroup和class类似
        
        initial begin
            repeat(4)begin           //生成得数据包的数量会影响覆盖率,也可以通过添加约束constraint来提升覆盖率,或者自定义bins。
                tr.randomize;        //随机化生成数据
                ck.sample();         //搜集覆盖率
            end
        end 
    
    endmodule
    
    

       覆盖率如下:使用Makefile实例三即可。在这里插入图片描述
      可以看出,两个覆盖点cport和cdata的覆盖率都较低,这是由于产生的随机化数据次数太少, 可以通过提高产生随机化的重复次数进一步提高覆盖率
    2)、在不添加约束constraint、不使用自定义bins,**改变随机化次数**的情况下:

            repeat(32)begin           //生成得数据包的数量会影响覆盖率,也可以通过添加约束constraint来提升覆盖率,或者自定义bins。
    

       在将repeat(4)改为repeat(32)后:覆盖率如下:
    在这里插入图片描述
      需要指出的是,提高随机化次数来提高覆盖率的方法只适用于,覆盖点的变量本身取值范围不大(如cport)的情况,如cdata自身取值范围太大,此方法便不再适用。此时可以通过添加约束constraint提高覆盖率
    在这里插入图片描述

    4.2.通过添加约束constraint、自定义bins——提高覆盖率(覆盖点变量取值范围大)

    1)、在自定义bins,而不添加约束constraint的情况下:

    module cov_demo();
    
      class transaction;
          rand bit[31:0]  data;        //2^32种可能
          rand bit[2:0]  port;         //0~7,一共8种可能
      endclass
        
       covergroup cov_port;
           port_bin : coverpoint tr.port;
           data_bin : covergroup tr.data{
                             bins min={[0:100]};        //此时,随机化生成该范围内任意一个数,该bins便被覆盖
                             bins mid={[101:9999]};
                             bins max={[10000:$]};       //$—-表示最大的边界
                          }
        endgroup
         
        transaction    tr=new;      //声明类的句柄,创建对象
        cov_port       ck=new;      //声明覆盖组的句柄,创建对象; covergroup和class类似
        
        initial begin
            repeat(32)begin           //生成得数据包的数量会影响覆盖率,也可以通过添加约束constraint来提升覆盖率,或者自定义bins。
                tr.randomize;        //随机化生成数据
                ck.sample();         //搜集覆盖率
            end
        end 
    
    endmodule
    

    在这里插入图片描述
    2)、在自定义bins,添加约束constraint的情况下:

    module cov_demo();
    
      class transaction;
          rand bit[31:0]  data;        //2^32种可能
          rand bit[2:0]  port;         //0~7,一共8种可能
          constraint data_c1{
                        data inside {[0:100],[101:9999],[10000:12000]};       //由于data的可能性太多,故对其施加约束
                        }
       endclass
        
       covergroup cov_port;
           port_bin : coverpoint tr.port;
           data_bin : covergroup tr.data{
                             bins min={[0:100]};        //此时,随机化生成该范围内任意一个数,该bins便被覆盖
                             bins mid={[101:9999]};
                             bins max={[10000:$]};       //$—-表示最大的边界
                          }
        endgroup
         
        transaction    tr=new;      //声明类的句柄,创建对象
        cov_port       ck=new;      //声明覆盖组的句柄,创建对象; covergroup和class类似
        
        initial begin
            repeat(32)begin           //生成得数据包的数量会影响覆盖率,也可以通过添加约束constraint来提升覆盖率,或者自定义bins。
                tr.randomize;        //随机化生成数据
                ck.sample();         //搜集覆盖率
            end
        end 
    
    endmodule
    

    在这里插入图片描述
    将随机化的次数改为320次后,repeat(320):覆盖率的hit次数变化分布不明显,如下图:可以通过施加权重调整hit的次数分布.
    在这里插入图片描述

    4.3.通过权重dist——调整hit次数分布

    将代码中的constraint约束调整为权重dist处理后,其各个bins的hit次数分布更加均匀,如下所示:

          constraint data_c1{
              data dist {[0:100]:/ 100, [101:9999]:/ 100, [10000:12000]:/ 120};      
                        }
    

    在这里插入图片描述

    展开全文
  • @unclebobmartin 100%的代码覆盖率无济于事,可以使您更安全,而事实并非如此。 @nicolas_frankel 100%的代码覆盖率不是成就,而是最低要求。 如果编写一行代码,则最好对其进行测试。 ...

    分支覆盖率 代码覆盖率

    本文的基础是我和罗伯特·马丁先生(2011年4月8日)之间的一系列推文:

    1. 如果覆盖率达到100%,则不知道系统是否正常运行,但是您确实知道编写的每一行都按您的预期工作。
    2. @unclebobmartin 100%的代码覆盖率无济于事,可以使您更安全,而事实与事实没有什么不同。
    3. @nicolas_frankel 100%的代码覆盖率不是成就,它是最低要求。 如果编写一行代码,则最好对其进行测试。
    4. @unclebobmartin我可以得到100%的代码覆盖率,并且不进行任何测试,因为如果没有断言。 停止将覆盖范围作为目标,这只是一种方法!

    这让我有些无语,甚至更多来自像马丁先生那样受人尊敬的人。 由于我的论点远远超出了140个字符的限制,因此,我准备了一个完整的文章。

    代码覆盖率没有任何测试

    让我们从M. Martin的基本断言开始,即100%的代码覆盖率确保每条代码行的行为均符合预期。 没有东西会离事实很远!

    代码覆盖率只是一种跟踪测试执行过程中流经过的位置的方法。 由于覆盖范围是通过检测实现的,因此代码覆盖范围也可以在执行标准应用程序期间进行测量。

    但是,测试是通过提供输入并验证输出是否是所需的代码来执行一些代码。 在Java应用程序中,这是在诸如JUnit和TestNG之类的框架的帮助下在单元级别完成的。 两者都使用assert()方法检查输出。

    因此, 代码覆盖率和测试是完全不同的东西 极端地讲,我们可以代码覆盖整个应用程序,即达到100%,而不必测试任何一行,因为我们没有断言!

    100%覆盖意味着测试所有内容

    并非我们所有的代码都不是关键也不复杂。 实际上,有些甚至可以说是彻头彻尾的琐事。 任何疑问? 然后考虑吸气剂和二传手。 即使任何值得一试的IDE都能为我们忠实地生成它们,是否应该对其进行测试? 如果答案是肯定的,则还应该考虑测试所使用的框架 ,因为与生成的getter和setter相比,它们是bug的来源更大。

    目标与实现方式之间的混淆

    M. Martin的第二个主张是要求代码覆盖率达到100%。 我希望有所不同,但是我使用“要求”一词具有不同的含义。 业务分析师将业务需求转换为功能需求,而架构师将其转换为非功能需求。

    代码覆盖率和单元测试只是减少bug发生率的一种方式,而并非必需条件。 实际上,只要软件满足他们的需求,用户就不会在乎平均代码。 只有IT部门,并且只有在应用程序寿命长的情况下,才可能对高代码覆盖率感兴趣 ,甚至没有100% 的兴趣

    成本效益

    我了解到,在某些特定情况下,软件不会失败:在外科手术或航空航天领域,生命受到威胁,而在金融应用程序中,单次失败可能造成数百万甚至数十亿美元的损失。

    但是,到目前为止,我微不足道的经验告诉我,无论我们是否想要,钱都占了上风。 等式非常简单:测试的成本是多少,错误的成本是什么,其可能性如何。 如果错误的代价是人类的生命,并且可能性很高,那么最好像地狱般对应用程序进行测试。 相反,如果错误的成本为半个工日,且可能性很低,为什么我们要花1个工日来进行提前纠正呢? 技术债务的观点有助于我们回答这个问题。 而且,这是经理必须在IT的帮助下做出的决策。

    重点是, 在大多数软件中 ,实现100%测试(而不是100%覆盖率)是过头的

    为了它

    最后但并非最不重要的一点是,我在我的工作中看到了一些有趣的异常行为。

    首先是质量是为了质量。 我是一名技术人员,我必须承认:“哇,如果我对此进行测试,我可以获得1%的代码覆盖率!” 有必要吗? 更重要的是,它增加了可维护性或降低了错误的可能性吗? 在任何情况下,您都应该问自己这些问题。 如果两个答案都不都是,那就算了。

    团队之间的挑战稍有不同。 挑战是好的,因为它们可以创建一个模拟并可以使每个人都变得更好,但是挑战的对象应该带来一些附加值,而原始代码覆盖率却没有。

    最后,我已经对此进行了讨论 ,但是那里的一些自负者只是在写简历而做事,100%的覆盖率只是其中之一。 这很不好,如果您对这些人有任何影响,则应努力使他们朝着更面向项目的目标(例如100%确定接受测试)进行定向。

    结论

    通过上述论点,我毫无疑问地证明了诸如“我们必须实现100%的代码覆盖率”或“这是要求”之类的断言不能被视为一般规则,并且在没有适当上下文的情况下完全是胡说八道。

    对于我自己,在开始项目之前,要做的事情之一就是与所有相关团队成员(主要是QA,PM和开发人员)就一定程度的代码覆盖率达成共识。 然后,我非常谨慎地解释说,此度量标准不是一成不变的,我列出了获取方法/设置方法,也没有断言是人为地增加它的方法。 代码越关键和越复杂,它应该具有的覆盖范围就越大。 如果可以选择的话,我宁愿没有达到约定的数量,也要经过严格的测试。

    对于团队来说,拥抱质量是一个值得追求的目标。 如果我们设定SMART目标,则甚至可以实现:100%的代码覆盖率仅是可衡量的,这就是为什么最好忘记它,越早越好,并专注于更多面向业务的目标的原因。

    翻译自: https://blog.frankel.ch/100-code-coverage/

    分支覆盖率 代码覆盖率

    展开全文
  • 代码覆盖率浅谈

    2021-01-31 14:15:28
    在做单元测试时,代码覆盖率常常被拿来作为衡量测试好坏的指标,甚至,用代码覆盖率来考核测试任务完成情况,比如,代码覆盖率必须达到80%或 90%。于是乎,测试人员费尽心思设计案例覆盖代码。用代码覆盖率来衡量...
  • 基于这个背景,我们需要统计增量代码覆盖率作为项目质量的参考指标之一,并集成到 DevOps 平台。方案1、先通过 git diff 统计代码差异,根据差异代码选择运行单元测试案例,最后得到差异覆盖率报告2、先运行全量单元...
  • 简介在测试中,为了度量产品质量,代码覆盖率被作为一种测试结果的评判依据,在Python代码中用来分析代码覆盖率的工具当属Coverage。代码覆盖率是由特定的测试套件覆盖被测源代码的程度来度量,Coverage是一种用于...
  • 检查代码覆盖率的源码。测试使用。
  • 结合故事书,赛普拉斯和开玩笑的代码覆盖率 请参阅。 这个项目展示了如何从Storybook收集代码覆盖率(例如,当使用进行视觉回归测试时)以及如何为3种类型的测试创建组合的代码覆盖率报告: 视觉回归测试(/) ...
  • 分支覆盖率 代码覆盖率 公共代码基金会致力于为国际公共组织(例如地方政府)启用开放和协作的公共目的软件。 为此,我们通过代码库管理在代码库级别支持软件。 我们还发布了公共代码标准 (在撰写本文时,其草稿...
  • Java代码覆盖率测试

    千人学习 2019-02-10 16:32:39
    本课程共分4个章节,分别由浅入深: 了解与查看jacoco的代码覆盖率; 自己在eclipse中编写一段代码,并编写单元测试,通过jacoco查看代码覆盖率; 自己编写一段代码,在ant中配置built.xml,实现编译、测试、生成...
  • 不管是否在项目中起着持续、有效的作用,代码覆盖率统计已经成为各产品组必备的工具。凭借丰富的覆盖率度量维度、灵活的数据管理与报告过滤方案和良好的工具支持,Jacoco成为部门内部技术成熟,使用广泛的工具。...
  • 分支覆盖率 代码覆盖率 (由Adobe Stock Photo许可) 互联网上现在有很多建议说100%的覆盖率不是一个值得的目标。 我非常不同意。 通常,难以测试的代码是需要重构的信号。 我知道了。 几年前,我很讨厌...
  • 原标题:如何分析 Python 测试代码覆盖率? 在测试中,为了度量产品质量,代码覆盖率被作为一种测试结果的评判依据,在Python代码中用来分析代码覆盖率的工具当属Coverage。代码覆盖率是由特定的测试套件覆盖被测源...
  • scala 代码覆盖率 Scala最好的代码覆盖率指标是语句覆盖率 。 就那么简单。 它最适合Scala中的典型编程风格。 Scala是一个变色龙,它可以看起来像您想要的任何东西,但是通常更多的语句写在一行上,而条件式“ if ...
  • 代码覆盖率和测试覆盖率If you’re aiming for test-driven development, you need to make sure that your code is getting properly covered by tests as you go. Originally released with 2019.3, the Code ...
  • 在做单元测试时,代码覆盖率常常被拿来作为衡量测试好坏的指标,甚至,用代码覆盖率来考核测试任务完成情况,比如,代码覆盖率必须达到80%或 90%。于是乎,测试人员费尽心思设计案例覆盖代码。用代码覆盖率来衡量...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 6,352
精华内容 2,540
关键字:

代码覆盖率