测试覆盖率是软件测试中的一种统计数据，它反映了一组测试执行了多少测试。它将包括确定在测试套件期间执行程序的哪些部分，以确定是否采用了条件语句分支。
这是确保您的测试正在测试您的代码或确定在整个测试过程中执行了多少代码的一种方法。
代码覆盖率和测试覆盖率通常被混淆。尽管基本概念相同，但它们并不相同。
必须至少针对代码的所有区域一次并由开发人员执行的单元测试过程称为代码覆盖率。
另一方面，测试覆盖率包括对每个需求至少进行一次测试，这显然是 QA 团队的职责。
每个团队的意见决定了真正算作涵盖的必需品。
如果某个需求至少有一个针对它的测试用例，则认为该需求已被某些团队覆盖。如果至少有一名团队成员被分配到它，它偶尔会被覆盖。或者，如果与其相关的所有测试用例都已完成。
如果有 10 个需求并且生成了 100 个测试，如果 100 个测试涵盖所有 10 个标准，我们就称其为设计级别的可接受测试覆盖率。
当仅运行 80 个计划的测试并且仅满足 6 个标准时。我们声称尽管已经完成了 80% 的测试，但仍未达到四项要求。这是执行级别的覆盖信息。
我们声明测试分配覆盖率为 80%，当只有 90 个与 8 个需求相关的测试有测试人员分配给他们，其余的没有。（十分之八）先决条件
知道何时计算覆盖率也很重要。
如果您在流程中过早地这样做，您会看到很多差距，因为仍然缺乏组件。因此，通常建议等到最后构建，也称为最终回归构建。这保证了为所提供的需求执行的测试被适当地覆盖。
识别测试用例集合未涵盖的需求区域
它有助于创建新的测试用例以提高覆盖率。
开发可量化的测试覆盖率指标作为质量控制的间接技术
识别无用的测试场景，这些场景无助于增加覆盖率。
查找一组测试用例未涵盖的需求部分
它有助于设计额外的测试用例以增加覆盖率。
开发可衡量的测试覆盖率度量作为间接质量控制方法
识别无用且不会增加覆盖率的测试用例
它可以保证测试是高质量的。
它可以帮助您确定代码部分是否因发布或修复而更改。
它可以帮助您在应用程序中找到未经测试的路由。
防止故障扩散。
时间、范围和成本都是可以控制的。
在项目的生命周期中应尽早避免缺陷。
它可以找出应用程序的所有决策点和路径，从而提高测试覆盖率。
在单元和代码级别，可以快速识别需求、测试用例和问题中的差距。
一切都取决于对周围环境的了解 -
首先，QA 团队必须了解项目的范围和设计工作的当前状态。如果以这种方式实施进一步的测试，他们将收到警报。作为典型的做法，您可以使用 RTM 来实现这一点。
其次，研究资源分配和测试执行技术，以确保尽快测试所有内容。
每个测试人员都应该熟悉需求和测试方法。
优先考虑您的需求，并将您的努力集中在最需要的地方。
请注意新版本与以前版本的不同之处，以便您可以更准确地确定关键需求并最大限度地扩大有利的覆盖范围。
测试自动化应该改变。
使用测试管理软件确保您始终保持最新状态。
分配智能工作 - 将您最好的员工集中在关键任务上，同时允许新测试人员从全新的角度发现更多。
使用清单跟踪所有工作和其他活动
为了更好地掌握应用程序的行为，请与您的开发/Scrum/BA 团队进行更多的互动。
跟踪您的所有构建周期和修复。
请注意新版本与以前版本的不同之处，以便您可以更准确地确定关键需求并最大限度地扩大有利的覆盖范围。
资源混乱- 为您的团队成员分配职责。这增加了参与度，同时避免了信息过载。
兼容性覆盖- 在测试您的应用程序时，请确保您了解并包含所有不同的浏览器和操作系统。
问责制- 让测试人员承担责任，并让他们完全控制他们正在处理的模块/任务（当然还有监控和指导）。这鼓励了问责制，并允许他们尝试新的策略，而不是固守经过验证的方法。
截止日期- 在开始测试过程之前了解发布截止日期可能有助于降低计划效率。
在发布周期之间与开发和其他团队保持联系，以随时了解正在发生的事情。
Keep an RTM - 这对于利益相关者和客户来说是一个有用的衍生工具，可以确认发布时间表。
按照下面提到的步骤来评估测试覆盖率 -
步骤 1 - 确定您正在评估的应用程序中的代码行总数。
Step 2 - 所有测试用例当前正在执行的代码行总数。
(X 除以 Y) 现在必须乘以 100。这个计算的结果是你的测试覆盖率 %。
如果一个系统组件有 500 行代码并且在所有当前测试用例中执行了 50 行，则您的测试覆盖率是 -
(50 / 500) *100=10%
是的，在评估产品的测试覆盖率时，要考虑的基本问题是：产品的哪些部分已经过测试，哪些没有？
示例 1 - 在测试时不要担心“刀”是否正确切割蔬菜/水果。用户舒适地处理它的能力是另一个需要考虑的因素。
示例 2 - 如果您正在评估一个名为“记事本”的程序，您需要查看相关方面。其他需要考虑的因素包括应用程序在使用其他应用程序时是否正确响应、应用程序是否在用户尝试执行异常操作时崩溃、用户是否收到适当的警告/错误消息、用户是否可以轻松理解和使用该应用程序，以及需要时是否提供帮助内容。
如果您不研究上述案例，就不能断言该应用程序的测试覆盖范围很广。
风险覆盖是广泛测试覆盖的另一个方面。在您还测试了产品或应用程序附带的威胁之前，您不能称其为“已测试”。相关的危害覆盖是整体测试覆盖的重要组成部分。
示例 1 - 如果测试人员告诉您他或她已经彻底检查了飞机的内部系统并发现它们处于良好的工作状态，但在测试期间仅飞机的飞行能力没有得到解决，您的反应是什么？
毕竟，这就是风险保障的含义。识别和彻底测试应用程序/产品特有的危害始终是一个好主意。
示例 2 - 在测试电子商务网站时，测试人员忘记考虑大量客户同时访问该网站的可能性，这被证明是 Super OFFER Day 的一个重大疏忽。
如果不能满足客户的需求，那么开发好的产品或应用程序是没有意义的。在测试期间，产品覆盖率与需求覆盖率同等重要。
示例 1 - 因为您期待家人团聚，所以您请裁缝为您制作连衣裙，并在领口上添加了孔雀蓝的纽扣。
裁缝认为在缝制衣服时将这些纽扣放在领口上会令人不快，所以他绣了一条金色的边框。试用当天，心怀不满的顾客无疑对裁缝不按指示大喊大叫。
示例 2 - 测试人员在测试聊天应用程序时处理了所有重点，例如多个用户在一个组中聊天，两个用户独立聊天，所有类型的表情符号可用，立即向用户发送更新等等，但是忘记看需求文档了，上面写得很清楚，两个用户独立聊天时，应该开启视频通话选项。
客户吹捧聊天工具允许两个人在互相通话时单独进行交流。您可以想象如果聊天程序发生这种情况会发生什么。
缺点：
缺点 - 因此，评估需求和开发测试用例需要大量时间。
您可以计算功能并将它们与使用测试覆盖率的大量测试进行比较。但是，判断错误的可能性总是存在的。