测试覆盖率和代码覆盖率是衡量代码有效性的最流行方法。这些术语有时会同时出现，因为它们的基本原理相同。但是它们并不是那么一致。很多时候，测试团队和开发团队对这两个术语的使用感到困惑。下面详细讨论代码覆盖率和测试覆盖率之间的区别的原因。
创新互联公司总部坐落于成都市区，致力网站建设服务有网站建设、成都网站建设、网络营销策划、网页设计、网站维护、公众号搭建、小程序开发、软件开发等为企业提供一整套的信息化建设解决方案。创造真正意义上的网站建设，为互联网品牌在互动行销领域创造价值而不懈努力！
代码覆盖率：表示通过用Selenium或任何其他测试自动化框架进行的手动测试和自动化测试，测试用例覆盖的代码百分比。例如，如果源代码具有一个简单的if...else循环，则如果测试代码可以覆盖这两种情况（即if＆else），则代码覆盖率将为100％。
测试范围：包括测试作为功能需求规范，软件需求规范和其他必需文档的一部分而实现的功能。例如，如果要对Web应用程序执行跨浏览器测试，以确保应用程序可以在其他浏览器流畅运行。测试覆盖范围是已验证Web应用程序的浏览器兼容性的浏览器+操作系统组合的数量。
开发人员在单元测试期间执行代码覆盖，以验证代码实现，尽可能多执行代码语句。大多数代码覆盖率工具都使用静态工具，将监视执行的语句插入代码中的必要位置。尽管添加检测代码会导致总体应用程序大小和执行时间增加，但与通过执行检测代码生成的信息相比，开销却很小。输出包含一个详细描述测试套件测试范围的报告。
单元测试主要用于在单个单元级别上测试代码。由于单元测试是由开发人员自己编写的，因此他对应该作为单元测试的一部分包含的测试具有更好的可见性。单元测试有助于提高软件的整体质量，但是关于构成单元测试的测试数量始终存在疑问。测试套件中是否有足够数量的测试方案？我们应该添加更多测试吗？代码覆盖率是所有这些问题的重要衡量标准。
随着产品开发的进行，新功能以及BUG修复补丁将添加到发布周期中。这意味着测试代码可能还需要进行更改，以使其与开发过程中所做的软件更改保持一致。在项目开始时设定的测试标准必须与后续的发布周期保持一致，这一点很重要。代码覆盖率可用于确保测试过程符合这些标准，并且质量最好的代码进入生产阶段。
代码覆盖率越高，发生未检测到的错误的概率越低。在某些组织中，质量团队设置在将软件推向生产阶段之前需要实现的最小代码覆盖量。这样做的主要原因是为了减少在产品开发的后期阶段检测到错误的可能性。
代码覆盖范围有不同的级别，代码覆盖率的一些常见的类型为：
为了检查代码覆盖率，使用了一种称为检测的方法。工具可用于监视性能，插入跟踪信息以及诊断源代码中的任何类型的错误。
仪器分为三种主要类型
根据测试要求，团队应该选择正确的代码覆盖率工具以及该工具支持的最佳检测方法。
有许多支持不同编程语言的代码覆盖工具，其中许多还可以兼用作QA工具。许多工具可以与构建工具和项目管理工具集成在一起，从而使它们更加强大的作用。选择开源代码覆盖率工具时，应检查该工具支持的功能以及该工具是否正在积极开发迭代中。下面是一些流行的开源代码覆盖工具：
与代码覆盖率是白盒测试方法不同，测试覆盖率是黑盒测试方法。以最大范围覆盖FRS（功能需求规范），SRS（软件需求规范），URS（用户需求规范）等中提到的需求的方式编写测试用例。
像代码覆盖率一样，也可以通过不同类型的测试来评估测试覆盖率。但是，应遵循哪种测试完全取决于具体的业务。例如在以用户为中心的Web应用程序中，可能存在UI/UX测试比功能测试具有更高优先级的情况，而在其他类型的应用程序中（例如银行，金融）；可用性测试，安全性测试等可能更为重要。
以下是一些测试覆盖率机制：
要注意的另一个重要点是，测试覆盖范围的目的和含义可能会有所不同，具体取决于执行测试的级别。它还取决于执行黑盒测试的产品类型。用于测试手机的测试覆盖率指标将不同于用于网站测试的指标。一些分类如下：
在代码覆盖率的情况下，度量标准是通过测试用例/测试套件测试的代码的百分比。因此，可以量化测试结果，即在100 LOC（代码行）中，代码覆盖率为80行。这意味着代码覆盖率为80％。由于执行测试是为了验证功能要求，因此无法量化测试覆盖率的结果。还可以提出可以在单个测试中测试多个需求的黑匣子测试。 尽管在少数情况下必须编写测试代码来达到测试覆盖率要求，但是在某些情况下，您可能仍需要使用一些流行的测试框架。两种最受欢迎 的测试框架是：
衡量代码覆盖率和测试覆盖率的影响的基础完全不同。代码覆盖率是通过测试期间覆盖的代码百分比来衡量的，而测试覆盖率是通过测试覆盖的功能来衡量的。 重要的是“其中哪一项最适合项目”？这个问题没有确切的答案，因为解决方案取决于项目的类型和复杂性。在大多数情况下，使用测试覆盖率和代码覆盖率，因为它们在软件项目中同等重要。
测试团队应花费大量时间来了解总体要求并确定测试活动的优先级。为了跟踪进度，他们应该有一个清单，该清单应定期更新（至少在每次发行之后）。测试团队还必须与质量保证（QA）团队保持频繁的沟通，这是很重要的，因为他们具有要发布给客户/客户的产品/项目必须达到的目标（测试/代码）覆盖范围的详细信息。没有专门的经验法则提到测试产品时需要达到的最小代码覆盖率或测试覆盖率百分比。
追求覆盖率只是手段而不是目的。测试同学的终极目的还是要在首先的资源情况下最大显得保障产品质量。不能因为KPI就盲目追求手段的极致，反而本末倒置，最终陷入泥潭不能自拔。
三种。codecover有三种运行方式。codecover意思为代码覆盖，代码覆盖率是衡量验证进展的最简易的方式。它的作用是检查代码是否冗余,设计要点是否遍历,被检测的对象是RTL代码,而代码覆盖率的检测由工具自动生成的。
语料库文件以特殊格式编码。这是种子语料库和生成语料库的相同格式。
下面是一个语料库文件的例子：
第一行用于通知模糊引擎文件的编码版本。虽然目前没有计划未来版本的编码格式，但设计必须支持这种可能性。
下面的每一行都是构成语料库条目的值，如果需要，可以直接复制到 Go 代码中。
在上面的示例中，我们在 a []byte后跟一个int64。这些类型必须按顺序与模糊测试参数完全匹配。这些类型的模糊目标如下所示：
指定您自己的种子语料库值的最简单方法是使用该 (*testing.F).Add方法。在上面的示例中，它看起来像这样：
但是，您可能有较大的二进制文件，您不希望将其作为代码复制到您的测试中，而是作为单独的种子语料库条目保留在 testdata/fuzz/{FuzzTestName} 目录中。golang.org/x/tools/cmd/file2fuzz 上的file2fuzz工具可用于将这些二进制文件转换为为[]byte.
要使用此工具：
语料库条目：语料库 中的一个输入，可以在模糊测试时使用。这可以是特殊格式的文件，也可以是对 (*testing.F).Add。
覆盖指导： 一种模糊测试方法，它使用代码覆盖范围的扩展来确定哪些语料库条目值得保留以备将来使用。
失败的输入：失败的输入是一个语料库条目，当针对 模糊目标运行时会导致错误或恐慌。
fuzz target： 模糊测试的目标功能，在模糊测试时对语料库条目和生成的值执行。它通过将函数传递给 (*testing.F).Fuzz实现。
fuzz test： 测试文件中的一个被命名为func FuzzXxx(*testing.F)的函数，可用于模糊测试。
fuzzing： 一种自动化测试，它不断地操纵程序的输入，以发现代码可能容易受到的错误或漏洞等问题。
fuzzing arguments： 将传递给 模糊测试目标的参数，并由mutator进行变异。
fuzzing engine： 一个管理fuzzing的工具，包括维护语料库、调用mutator、识别新的覆盖率和报告失败。
生成的语料库： 由模糊引擎随时间维护的语料库，同时模糊测试以跟踪进度。它存储在$GOCACHE/fuzz 中。这些条目仅在模糊测试时使用。
mutator： 一种在模糊测试时使用的工具，它在将语料库条目传递给模糊目标之前随机操作它们。
package： 同一目录下编译在一起的源文件的集合。
种子语料库： 用户提供的用于模糊测试的语料库，可用于指导模糊引擎。它由 f.Add 在模糊测试中调用提供的语料库条目以及包内 testdata/fuzz/{FuzzTestName} 目录中的文件组成。这些条目默认使用go test运行，无论是否进行模糊测试。
测试文件： 格式为 xxx_test.go 的文件，可能包含测试、基准、示例和模糊测试。
漏洞： 代码中的安全敏感漏洞，可以被攻击者利用。
可以按逐行代码甚或逐个代码块的形式衡量测试的有效性。可以通过配置测试运行以产生代码覆盖率数据来做到这一点。得到的数据显示在“代码覆盖率结果”窗口和源代码文件中。
当对项目（通常为二进制文件）进行了检测，并在测试运行期间将其加载到了内存中时，就会收集代码覆盖率数据。获取代码覆盖率数据过程介绍了如何选择要检测的文件。
注意默认情况下，在运行单元测试时测量代码覆盖率。因此，在运行单元测试时，只有在已关闭代码覆盖率数据收集功能，或者当您希望对其他项目进行检测以收集它们的代码覆盖率数据时，才需要执行获取代码覆盖率数据中的步骤。测试运行完成后，即可查看代码覆盖率数据；有关更多信息，请参见查看代码覆盖率数据。
还可以合并多组代码覆盖率数据，如如何：合并代码覆盖率数据中所述。有关与合并代码覆盖率数据有关的各种情况的信息，请参见使用合并的代码覆盖率数据。如对程序集进行检测和重新签名中所述，必须对经过检测的具有强名称的程序集进行重新签名。指定密钥文件即可启用重新签名。有关更多信息，请参见重新签名程序集。
必须显式地对项目进行检测，只有这样，才能在您运行单元测试之外的其他测试时获取代码覆盖率数据。例如，某个运行手动测试的测试人员可能会启动一个特殊的程序。如果这个程序的二进制文件经过了检测，则将收集代码覆盖率数据。有关更多信息，请参见手动测试概述。
获取代码覆盖率数据获取代码覆盖率数据创建代码测试。这些测试既可以是单元测试，也可以是其他测试类型（它们执行您已为其设置了符号并且已为其选择了要检测的适当二进制文件的代码）。有关如何创建单元测试的信息，请参见
如何：生成单元测试。
打开将用于单元测试的测试运行配置。
有关更多信息，请参见如何：指定测试运行配置。单击“代码覆盖率”。在“选择要检测的项目”下，选择解决方案的
DLL、可执行文件或目录。例如，如果解决方案的名称为
ClassLibrary1，则选择名为
ClassLibrary1.dll、路径为
Solution
Directory\ClassLibrary1\bin\Debug
的程序集所对应的复选框。注意也可以选择包含测试项目文件的
DLL。这将为测试项目中的方法（而不仅仅是生产代码中的方法）生成代码覆盖率数据。
单击“应用”，再单击“关闭”。运行一个或多个测试。
有关更多信息，请参见如何：运行选定的测试。在运行测试时，会收集代码覆盖率数据。有关查看数据的更多信息，请参见查看代码覆盖率数据。
注意运行VSPerfMon.exe
可以与代码覆盖率数据的集合进行交互。有关更多信息，请参见
Team
Edition
for
Testers
疑难解答中的“代码覆盖率数据和
VSPerfMon.exe”部分。无法为运行在
64
位进程中的应用程序收集代码覆盖率数据。因此，如果您在测试此类应用程序时请求了代码覆盖率数据，则测试引擎会在要检测的程序集的可移植可执行
(PE)
标头中设置“32BIT”标志。测试运行完成后，程序集会恢复到其原始状态。重新签名程序集重新签名程序集打开将用于单元测试的测试运行配置。
有关更多信息，请参见如何：指定测试运行配置。单击“代码覆盖率”。单击“用于重新签名的密钥文件”文本框旁边的省略号
(…)。将显示“选择一个密钥文件”对话框。选择一个密钥文件，然后单击“打开”。在测试运行配置编辑器中，单击“应用”，再单击“关闭”。
如果您要测试多个已签名的程序集，Visual
Studio
会尝试重新签名使用您指定的密钥文件签名的所有具有强名称的程序集。有关更多信息，请参见对程序集进行检测和重新签名中的“重新签名程序集”。
查看代码覆盖率数据先决条件：已经运行已生成代码覆盖率数据的测试，如获取代码覆盖率数据中所述。
查看代码覆盖率数据在“测试结果”工具栏上，单击“代码覆盖率结果”。或者，也可以单击“测试”菜单上的“窗口”，然后单击“代码覆盖率结果”。
将打开“代码覆盖率结果”窗口。
在“代码覆盖率结果”窗口中，“层次结构”列显示一个节点，其中包含有在上一次测试运行中获取的所有代码覆盖率数据。如果发生了错误，则在此位置（而非根节点中）显示错误信息。如果显示有节点，请将其展开。注意默认情况下，该测试运行节点采用
用户名@计算机名
日期
时间
的格式命名。可以在“选项”对话框的“常规”页上更改默认命名方案。有关更多信息，请参见如何：指定测试运行配置。依次展开程序集、命名空间和成品代码中某个类的节点。
类中的各行表示类的方法。此表中的列显示了各个方法、类和整个命名空间的覆盖率统计数据。
双击类中的一个方法所对应的行。
将打开源代码文件并转到您选择的方法。在此文件中，可以看到代码突出显示效果。通过滚动，可以看到此文件中其他方法的覆盖率。要更改代码行的突出显示颜色，请参见更改代码覆盖率数据的显示。注意可以单击“测试工具”工具栏上的按钮以切换文件中代码覆盖率的显示，以及导航到文件中前面的或后面的代码行。
（可选）如果选中了测试项目的
DLL
所对应的复选框，则可以打开包含单元测试的源代码文件，以查看执行了哪些测试方法。
更改代码覆盖率数据的显示默认情况下，将使用特定的颜色来指示代码是否被已运行的测试覆盖了。用浅蓝色突出显示的代码行已在测试运行中执行过，而用红褐色突出显示的代码行则还没有执行过。在用米色突出显示的代码行内，有些代码已执行过，有些代码则还没有。
更改代码覆盖率数据的显示单击“工具”，然后单击“选项”。将显示“选项”对话框。
展开“环境”。单击“字体和颜色”。
在“显示其设置”下，选择“文本编辑器”。在“显示项”下，选择要更改其显示颜色的代码覆盖率区域。可用的选项有“覆盖率未涉及的区域”、“覆盖率部分涉及的区域”和“覆盖率涉及的区域”。更改此代码覆盖率区域的设置。可以更改前景色和背景色、字体、字号和文本的粗体设置。（可选）更改其他代码覆盖率区域的设置。
完成上述操作后，单击“确定”。
