品质管理 如何量化测试覆盖率

ippppp · 发布于 2017年09月11日 · 最后由 chenhengjie123 回复于 2017年09月14日 · 462 次阅读

一、场景

  • 通常情况下,项目经理or项目总监会分阶段的问测试负责人,本阶段的测试覆盖率是多少?

二、我的理解

  • 测试覆盖率应该区分自动化测试覆盖率功能测试用例覆盖率
  • 对于自动化测试覆盖率,应是=(自动化测试脚本执行过的代码/总代码)
  • 对于测试用例覆盖率,应是=(测试用例覆盖的功能点/产品设计的所有功能点)

三、问题

  • 在上述一、场景下,如何区分高层想要的测试覆盖率到底是哪一种?对高层领导而言,测试覆盖率到底是一种什么样意义的数据?
  • 对于自动化测试覆盖率:1、上述公式是否可用,或者说我的理解是否对?;2、目前没有按上述公式进行过尝试,是否拥有可行性?
  • 对于功能测试用例分析:1、与自动化测试覆盖率相同,对上述公式的理解是否正确?;2、实际在准备功能测试用例时,必定是针对每个功能点都准备测试用例,包括正常和异常的验证。那基本测试用例覆盖率都是100%?这样还有什么意义呢?

上述是我个人遇到的难点,还请各位有遇到或者思考过这个问题点的前辈指正~

共收到 12 条回复
10279

(自动化测试脚本执行过的代码/总代码)
至少可以分为: 行覆盖 跟 逻辑覆盖 就区别很大!

100%的逻辑覆盖 几乎是不可能实现的!

605

公式我觉得没啥问题,但可行性建议你考虑下:

  1. 产品设计的所有功能点这个比较难量化,需求的形式千变万化,很难统计。
  2. 自动化测试的覆盖率,从你的理解上看应该是代码覆盖率中的行覆盖率了。初期用这个确实可以,但要收集覆盖率,你需要衡量好现有的工具使用难度,以及自动化水平是否已经到达可以统计这个覆盖率的程度。

这些覆盖率如果收集起来非常费事且难以统一,最后还是没啥用的。建议先找下,老大们想要的是怎样的覆盖率。说不定只是作为一个参考值,那只需要用例里体现就好,比如开始阶段全用例执行,覆盖率90%,后面主要执行高优先级,覆盖率是 高优先级用例/全用例 。

72014a
605chenhengjie123 回复

感谢!

1、功能测试用例的覆盖率:从楼上第一点来看,是否可以总结为:因为无法量化明确+隐含需求,导致功能测试用例的覆盖率无法统计,或者只能估计?
2、自动化测试的覆盖率:我问到的和查到的,大部分说的是单元测试的覆盖率。目前也还不知道哪种自动化工具可以实现统计回归测试的代码率。
3、我工作内,经常会被要求做测试覆盖率的说明。我查到的资料说的是,测试覆盖率的目的是检查未测试部分的代码,所以大部分的解释给的都是测试覆盖率=代码覆盖率

针对以上,感觉测试覆盖率由单元测试出结果。

72014a
10279mengde0077 回复

行覆盖和逻辑覆盖好像都是单元测试的内容

请问知道哪种自动化测试工具可以统计出代码的行覆盖or逻辑覆盖吗?

10279

如果是java 的话 用过 jacoco

72014a
10279mengde0077 回复

厉害了
得学java了😂

10279

手动测试 也可以使用 代码覆盖率工具来检查 ,执行的用例 到底覆盖了哪些代码,
可以检查 有什么遗漏的 分支场景,甚至可以发现开发的垃圾代码 或者 错误的逻辑 或者 不合理的 业务思路;

72014a
10279mengde0077 回复

还是要灰盒测试甚至白盒测试啊
黑盒这些都没法弄

16280
  • 覆盖率本身不重要,100%的覆盖率也不意味着没问题,环境、配置集成的问题占比不在少数
  • 非要看覆盖率,变更覆盖率才稍显更有价值一点,扫变更集,svn、git都支持拉变更文件清单
  • 覆盖率只要环境能允许,java的用sonarqube或者jacoco(推荐),手动自动都可以看
72014a
16280fudax 回复

厉害了👍 👍 👍
三条回复的每一条都要再仔细消化消化

605
72014aippppp 回复

我理解的覆盖率有两类:白盒角度的(代码/配置项执行层面)、黑盒角度的(需求要求的覆盖、需求以外补充场景的覆盖)。一般情况下,测试覆盖率说的是后者。

单元测试的代码覆盖率是白盒角度覆盖率的一种,也是代码覆盖率的一种最常见的应用。不过,前提是你们有单元测试,否则没什么卵用。

除了单元测试的代码覆盖率外,还有集成测试(你也可以理解为手工测试)的代码覆盖率,即直接获取一个正在运行中程序的代码覆盖情况。这种方法核心工具用的还是和代码覆盖率一致的覆盖率收集工具(java 用 jacoco,javascript 用 instanbul ),不过一般要配套平台来自动收集和生成报告(我所在的组现在就在做这个),否则使用步骤太复杂了,落不了地的。

这方面以前调研的时候写过一篇文章,有涉及到单测覆盖率和手工覆盖率获取方式的区别,你可以参考下,也许能够有些启发:
React Native 代码覆盖率获取探索 (一)
React Native 代码覆盖率获取探索 (二)

代码覆盖率如果没有足够的代码能力去好好分析和增加代码覆盖(比如你从报告看到第100行没有覆盖,有没有能力分析出这一行对应什么功能,评估通过什么样的用例可以覆盖,以及是否有覆盖的价值),其实就只是一个指标而已了。集成测试的变更覆盖率目前没有现成开源工具可用,必须自研(核心点在于如何把代码变更集融入到覆盖率报告的生成中),不过一些思路或者方法分享倒是有不少,你可以在社区找下,之前美团在他们的公众号好像也分享过一个。

建议你考虑清楚,你需要这个覆盖率到底是为了应付老大们的需要,还是真的为了精细地衡量好每次测试的情况,并逐步根据覆盖率情况去改进测试方法,提高覆盖率。如果是后者,才值得投入。前者的话,给个黑盒角度的大致覆盖率就足够了。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册