自动化测试指南-覆盖率

简介

测试覆盖率被用作衡量软件测试质量和有效性的指标。它是一种用于确定应用程序代码的测试覆盖率和测试运行时行使的代码量的方法，例如。如果有100个需求，为100个需求创建了100个测试，90个测试被执行，那么测试覆盖率为90%。这有助于了解测试中的差距，并为解决方案的覆盖率创建额外的测试。测试自动化在一些领域提供100%的测试覆盖率，如单元测试、性能测试、安全测试和数据验证。

测试覆盖率

衡量测试覆盖率的一个广泛接受的方法是基于功能和非功能需求。功能性和非功能性需求推动了对应用程序的期望。功能性需求描述了应用程序的预期行为，而非功能性需求描述了应用程序的可靠性和可持续性。

需求覆盖并不总是通过测试或测试自动化来实现，因为许多需求，如法律、标准和合规性，是通过静态测试和验证来实现的。测试跟踪矩阵是跟踪需求直到最终应用的最常用的方法，测试自动化确保测试覆盖率快速和一致地达到。各种工具，如Micro Focus ALM、微软Azure DevOps和Jira都可以用于需求追踪矩阵（RTM）。

'可追溯性是指两个或多个工作产品之间可以建立关系的程度。可追溯性矩阵是一个二维表，它将两个实体关联起来，例如需求和测试用例。该表允许来回追踪一个实体与另一个实体之间的联系，从而能够确定所实现的覆盖率，并评估拟议的变化的影响"（根据 ISTQB 术语表，https://glossary.istqb.org/app/en/search/）。

需求覆盖率和代码覆盖率是两个不同的概念，尽管它们经常被用来衡量相同的结果。代码覆盖率是一种常见的单元测试实践，它被广泛用于测量单元测试中实际使用了多少代码，单元测试中没有使用多少代码，还可以显示哪些分支被覆盖，哪些没有被覆盖。单元测试是软件开发活动的一部分，其责任在于程序员或开发人员。有各种工具可用于检查和优化单元代码覆盖率。

需求覆盖率是测试团队的责任。他们验证测试是否覆盖了所有从需求和其他验收标准得出的测试条件。需求追踪矩阵经常被用来追踪需求直到验收，是决定何时停止测试的一个关键参数。

单元测试覆盖率

单元测试通常由程序员编写，以验证代码的正确性。这是为了验证代码的编程是否符合程序标准和从产品积压或需求规格中得出的LLD(Low Level design)或详细设计文件(DDD detailed design document)。

LLD或DDD定义了所选逻辑选项的物理架构设计、服务器类型、网络架构、存储要求、接口、网络设计等。

一般来说，单元测试实现100%的自动化。然而，如果努力与受益不相称，就不应该进行单元测试，例如简单的对API的调用，代码中没有业务逻辑，就不会进行单元测试。

CIT，也被称为单元集成测试，是为了验证程序组件是否全部存在并能一起工作。在可能的情况下，CIT应该是百分之百的自动化。单元测试可以提高软件解决方案的质量，并在缺陷周期中更早地发现缺陷。单元测试通常在LLD开发，在微观层面执行。单元测试的关键输入是产品积压或需求、风格指南、代码或组件单元和LLD。它们一般在开发环境和开发工作站上进行。现成的软件工具和软件包供应商一般提供一个内置的测试框架，称为自动测试框架(ATF)，用于单元测试。

单元测试的目的是检测代码单元中的执行错误，例如函数、方法或存储过程。

单元测试的主要目的和好处：

• 良好的实践，在微观层面保证质量。
• 更早地在设计层面上发现缺陷。
• 基本组件或定制的代码单元按照其设计规范运作。
• 暴露出组件单元之间相互作用的问题。
• 验证组件的性能。
• 定制代码的可访问性符合要求。
• 验证编码标准。
• 检查自动构建。
• 所有的安装、配置和数据转换过程都成功执行。

自动单元测试减少了人工干预，测试是用编程语言编码的工具，并作为构建过程的一部分针对代码库执行。这些自动化测试在每次代码构建或发布后都会被执行，并对结果进行错误审查。开发人员使用单元测试结果来验证其代码的质量。

自动化单元测试为测试覆盖率提供了巨大的好处。关键的好处是。

• 与手工测试相比，经常使用，没有额外的费用
• 使得开发过程更加灵活
• 自动检查标准、合规性和准则
• 使得在开发周期中更快地发现问题
• 在编码过程中发现错误，加快开发速度
• 始终跟踪和监控代码质量
• 更快的构建验证，易于重构和清理现有代码
• 快速和详细的测试覆盖率，支持更快的错误修复、热修复和发布

功能和回归测试覆盖率

功能测试提供对功能需求的测试覆盖。测试场景和测试用例被映射到需求上，以确保它们对规范的覆盖。自动测试脚本直接映射到功能测试用例和需求上，提供了测试覆盖率的良好指示。

回归测试包的范围根据发布的范围而变化，如完全发布，热修复，补丁发布和常规发布。从需求映射到回归包的自动回归包提供了测试覆盖率的即时可见性。手动回归测试是单调的，一旦测试执行的频率很高，如果做得不正确，就不太有效。测试人员倾向于忽视测试，测试执行成为一种 "例行公事"，而不是一种深思熟虑的活动。测试自动化是一个很好的方法，可以使用不同的数据集使其更加有效和广泛。测试自动化是最适合回归测试的测试覆盖方法。

选择自动化的测试用例是根据各种因素进行的，如风险、投资回报率、时间因素、依赖性和大量数据。

冒烟测试通常用于验证已部署的构建是否稳定，是否准备好进一步的详细测试。它通常由构建和部署团队或测试团队执行。大多数烟雾测试都是自动化的，它们提供快速的结果。

自动化的功能测试提供快速的结果和完整的测试覆盖。集成测试是功能和系统测试的延伸，同样的自动化原则也适用于集成测试。技术集成测试，如网络服务测试、API测试和接口测试，通常是完全自动化的，并提供100%的测试覆盖率。

为了提供测试覆盖率，自动化功能测试的主要特点是。

• 提供一致的测试覆盖率
• 自动覆盖标准、合规和准则
• 对冒烟测试的完整测试覆盖
• 对功能进行快速和详细的测试覆盖

非功能测试覆盖率

非功能测试是检查系统的非功能方面，如软件应用的性能、可用性、可靠性、安全性、可及性和基础设施。它是根据非功能需求来测试系统的准备情况。测试自动化是一个适合广泛的非功能测试的解决方案，因为手动测试是不有效或不可行的。自动化的非功能测试是快速的，并提供对需求的全面测试覆盖。大多数非功能测试是完全自动化的，并提供良好的测试覆盖率，例如，性能测试、安全测试、浏览器测试和移动测试可以完全自动化，并提供100%的测试覆盖率。然而，可用性测试、用户体验和基础设施测试很难实现自动化，提供的测试覆盖率较低。

自动化非功能测试对测试覆盖率的主要好处是。

• 与手工测试相比，自动化的性能、数量和可扩展性测试提供高的测试覆盖率。
• 在安全测试中，工具和自动化对一致的测试覆盖率至关重要，例如渗透测试或漏洞扫描。

测量测试覆盖率的挑战

测试自动化为测试覆盖率带来了速度、信心、效率、可靠性和完整性，在软件测试中是必不可少的。然而，在使用自动化进行测试覆盖时，有一些挑战。

• 当需求不完整时，测试很难实现自动化，无法提供准确的测试覆盖。
• 低优先级的需求可能不符合自动化测试的条件。这可以减少通过测试自动化的测试覆盖水平。
• 不同测试阶段的测试覆盖率有不同的含义。测试自动化对于自动化单元测试来说是很高的。UAT一般是手动进行的，可能不适合自动化测试覆盖。
• 难以自动化的需求，不考虑自动化和自动化测试覆盖。
• 通过自动化测试实现百分之百的自动化和测试覆盖率是很难实现的，例如在可用性测试中。

测试自动化度量

测试自动化指标对于测试覆盖率和确保自动化测试的质量至关重要。测试自动化是一项巨大的投资，它需要持续的监控、跟踪和测量，以确保它能获得预期的收益并提供投资回报。如果不能测量，测试自动化和自动化测试的投资就不能被证明。

你无法管理你无法衡量的东西。(通常归功于W.Edwards Deming，这位统计学家和质量控制专家被认为发起了全面质量管理运动，有时也归功于Peter Drucker) 。

如果测试自动化和自动化测试的投资不能被衡量，就不能证明它的合理性。

• 测试自动化覆盖率的百分比
• 测试通过与否的百分比
• 自动化测试通过与失败的百分比与手动测试通过与失败的百分比
• 自动化脚本在一段时间内发现的缺陷数量，以评估脚本的有效性
• 手工测试发现的缺陷数量与自动化测试的缺陷数量对比
• 自动化的需求覆盖率
• 测试自动化工作与人工测试工作的对比