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

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

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

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

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

感谢！

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

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

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

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

如果是 java 的话 用过 jacoco

厉害了
得学 java 了

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

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

慢慢来

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

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

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

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

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

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

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

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