软件测试中的测试覆盖率
究竟什么是测试覆盖率？
在软件测试中，测试覆盖率被定义为一个统计数据，它表示一组测试完成的测试数量。它将需要获取有关在执行测试套件时执行程序的哪些部分的信息，以便确定是否采用了条件语句分支。
这是一种确保您的测试正在测试您的代码或您通过运行测试执行了多少代码的方法。
代码覆盖率和测试覆盖率
代码覆盖率和测试覆盖率经常被误解。尽管基本概念相同，但它们并不相同。
代码覆盖率是指必须至少针对代码的所有部分进行一次并由开发人员执行的单元测试程序。
另一方面，测试覆盖率需要对每个需求至少测试一次，这显然是QA团队的责任。
真正算作涵盖的需求是由每个团队的观点决定的。
例如，一些团队会考虑涵盖一个需求，前提是它至少有一个测试用例。如果至少有一名团队成员被分配到它，它偶尔会被覆盖。或者，如果与它相关的所有测试用例都运行。
如果有10个需求并且编写了100个测试，如果这100个测试针对所有10个标准并且没有遗漏任何一个，我们就将其称为设计级别的适当测试覆盖率。
当只执行80个准备好的测试并且只针对6个要求时。尽管已经完成了80%的测试，但我们声称还没有达到四个标准。这是执行级别的覆盖率数据。
当只有与8个需求相关的90个测试有测试人员分配给他们而其余的没有时，我们说测试分配覆盖率为80%。（10个要求中有8个）。
知道何时计算覆盖率也很重要。
如果您在此过程中过早地执行此操作，您会看到很多差距，因为项目仍然丢失。因此，通常建议等到最后一次构建，通常称为最终回归构建。这可确保正确覆盖针对提供的需求运行的测试。
测试覆盖率的目的是什么？
识别测试用例集合未涵盖的需求区域
它有助于创建新的测试用例以提高覆盖率。
开发可量化的测试覆盖率指标作为质量控制的间接技术
识别无用的测试场景，这些场景无助于增加覆盖率
如何实现测试覆盖率？
测试覆盖率可以通过使用静态审查技术来实现，例如同行审查、检查和演练。
通过将临时缺陷转换为可执行的测试用例
测试覆盖可以通过使用自动化代码覆盖或单元测试覆盖技术在代码或单元测试级别完成。
功能测试覆盖可以在适当的测试管理技术的帮助下完成。
测试覆盖的优势
它可以保证测试的质量。
它可以帮助确定代码的某些部分是否被实际修改以进行发布或修复。
它可以帮助识别应用程序中未经测试的路径。
防止缺陷的传播。
时间、范围和成本都可以管理。
在项目生命周期的早期预防缺陷
它可以确定应用程序的所有决策点和路径，从而提高测试覆盖率。
可以很容易地识别需求、测试用例以及单元和代码级别的问题中的差距。
一个好的测试覆盖率技术应该如何实现？
一切都围绕着意识-
首先，QA团队必须了解项目的范围和设计活动的状态。如果以这种方式引入进一步的测试，他们将收到通知。您可以使用RTM来执行此操作，这是常见做法。
其次，研究资源分配和测试执行程序，以确保尽可能快地测试所有内容。
您如何确保所有内容都经过测试？
每个测试人员都应该了解要求和测试程序。
优先考虑您的需求，并将您的努力指向最需要的地方。
请注意特定版本与之前版本的不同之处，以便您可以更准确地确定重要需求并专注于最大程度的正面报道
修改测试自动化
使用测试管理工具确保您始终保持最新状态。
智能工作分配-将您最优秀的人员集中在重要任务上，并允许新测试人员从不同的角度进行更多探索。
保留所有工作和其他活动的清单
与您的开发/Scrum/BA团队进行更多互动，以更好地了解应用程序的行为。
保留所有构建周期和修复的记录。
请注意特定版本与之前版本的不同之处，以便您可以更准确地确定重要需求并专注于最大程度的正面报道。
使用测试管理工具确保您始终保持最新状态。
智能工作分配-将您最优秀的人员集中在重要任务上，并允许新测试人员从不同的角度进行更多探索。
保留所有工作和其他活动的清单
与您的开发/Scrum/BA团队进行更多互动，以更好地了解应用程序的行为。
保留所有构建周期和修复的记录。
关键的高效测试领域和技术
资源混乱-在您的团队成员之间分配职责。这可以提高参与度，同时防止信息集中。
兼容性覆盖-确保您在测试应用程序时了解并包含各种浏览器和系统。
所有权-让测试人员承担责任，并给予他们完全自主权（当然还有监控和协助）他们正在处理的模块/任务。这培养了责任感，并使他们能够尝试新方法，而不是坚持经过验证的方法。
截止日期-在测试过程开始之前了解发布截止日期有助于低效规划。
沟通-在发布周期之间与开发和其他团队保持联系，以了解最新进展。
维护RTM-作为利益相关者或客户的良好衍生工具，允许确认发布时间表。
测试覆盖率计算公式
要确定测试覆盖率，请遵循以下概述的方法-
步骤1-您正在评估的程序质量中的代码行总数。
Step2-所有测试用例目前正在执行的代码行总数。
您现在必须将（X除以Y）乘以100。此计算得出您的测试覆盖率百分比。
例如-
如果您在一个系统组件中有500行代码并且50行代码在所有当前测试用例中运行，则您的测试覆盖率是-
10%=(50/500)*100
产品覆盖范围——您检查了产品的哪些部分？
是的，在衡量产品的测试覆盖率时，要关注的主要主题是-您测试了产品的哪些部分，哪些尚未测试？
示例#1-如果您正在测试“刀”，请不要担心它是否能正确地切蔬菜/水果。其他需要考虑的因素是用户舒适地处理它的能力。
示例#2-如果您正在评估名为“记事本”的应用程序，则需要检查相关功能。其他注意事项包括：应用程序在同时使用其他应用程序时正确响应，当用户尝试执行异常操作时应用程序不会崩溃，用户收到正确的警告/错误消息，用户能够轻松理解和使用应用程序，以及在需要时提供帮助内容。除非您调查上述场景，否则您不能说应用程序的测试范围是全面的。
风险覆盖–您检查了哪些风险？
全面测试覆盖的另一个组成部分是风险覆盖。在您还测试了相关危害之前，您不能将产品或应用程序标记为“已测试”。相关危害的覆盖范围是整个测试覆盖范围的关键组成部分。
示例#1-如果在测试飞机时，测试员告诉您他/她已经完全检查了飞机的内部系统并且它运行正常，但只有飞机的飞行能力有问题，您的反应是什么？测试期间没有被覆盖？毕竟，这就是风险保障所包含的内容。识别特定于应用程序/产品的风险并对其进行正确测试始终是一种明智的方法。
Example#2-在测试电子商务网站时，测试人员评估了每一个有效的功能，但没有考虑到大量消费者同时访问网站的潜力，这在SuperOFFER日被证明是一个重大错误.
要求的覆盖范围——您测试了哪些要求？
如果产品或应用程序开发得很好，但不能满足客户的需求，则它是无用的。产品覆盖与测试期间的需求覆盖一样重要。
示例#1-由于您对家庭聚会感到兴奋，因此您要求裁缝缝制您的裙子并在领口上添加那些孔雀蓝显示纽扣。在缝制衣服时，裁缝认为将这些纽扣放在领口上会不吸引人，所以他绣了一条金色的边框。当然，在试用当天，不满意的客户会因为不遵守规格而对裁缝大喊大叫。
Example#2-在测试聊天应用程序时，测试人员负责所有重要的点，例如多个用户在一个组中聊天，两个用户独立聊天，所有类型的表情符号可用，立即向用户发送更新等等，但是忘记看需求文档了，里面明确说两个用户独立聊天时，应该开启视频通话选项。客户宣传聊天程序允许在两个人独立交谈时进行通话。如果发生这种情况，您可以想象聊天应用程序会发生什么。
缺点
因为测试覆盖手册中没有工具可以自动化大部分活动。因此，需要大量时间来评估需求和开发测试用例。
测试覆盖率允许您计算功能，然后将它们与许多测试进行比较。然而，在判断上总是有失误的余地。