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