深入探讨软件测试的质量度量指标

本文的目的是介绍项目中使用到主要质量指标，这些质量指标可以分为以下三类：

1. 质量保证过程指标
2. 生产事故管理指标
3. 度量质量文化指标

质量保证过程指标

质量保证指标可以通过测试覆盖率来度量功能和非功能测试的覆盖率，同时也可以根据测试发现的缺陷的状态、优先级和关键程度来度量质量，最终目的是提高用户的满意度。以下是常见的指标分类：

1. 测试覆盖率：可以使用各种标准来度量，具体取决于测试类型。这些指标提供了对团队和产品内测试演变的洞察，以及了解代码行和用户故事方面的覆盖范围。此外，自动化水平表明整体质量活动的改进并减少了认证时间。(a)在单元测试中，度量是否符合已建立的质量门是至关重要的，以确保代码在其最原子级别正确运行并遵守单元测试指南。验收测试通过考虑每个用户故事可用的测试用例数量来评估覆盖率。（二）它们通常按测试类型（例如冒烟、理智、回归、集成）、优先级以及它们是手动测试还是自动测试来组织。这些测试包括来自 UI 级别的端到端场景和来自后端的 API 测试场景。
2. 测试执行时间：该指标度量验证用户故事所需的时间，同时考虑执行的测试的数量和类型，以及在发现缺陷的情况下重新运行测试所需的时间。随着手动测试水平的提高，用于确保质量和交付生产功能的时间也会增加。考虑自动测试与手动测试的时间，目的是优化时间并尽早执行测试，无论是在开发周期开始时还是通过在整个过程中进行连续测试。
3. 代码复杂性：代码质量可以使用不同的指标来度量，包括代码行数、最佳实践和开发技术，以及复杂性循环的数量。静态代码分析工具用于获取此信息，从而可以识别软件质量问题，例如漏洞和“代码气味”等。一些最著名的工具包括 Sonarqube、Checkmarx、PMD、Codacy 和 Deep Source 等。
4. 缺陷率：该指标根据发现的缺陷数量度量软件质量，并根据环境、优先级、严重性和状态进行分类，重点关注关键缺陷或在生产中检测到的缺陷。关键缺陷数量少表明软件质量更高，解决这些缺陷的能力也更快。根据该指标，如果存在大量严重缺陷，则可以实施“零错误”政策，规定如果发现严重缺陷，必须立即处理和解决。
5. 用户满意度指数：该指标度量用户对系统的满意度。高满意度指数表明该软件满足用户期望。可以使用不同的方法来度量用户满意度指数，例如调查、投诉、应用程序商店中的评估、可用性测试以及用户检测到的关键缺陷的百分比。重要的是使用工具来监控和了解用户行为，以改进或计划可以增强用户体验并因此提高他们满意度的任务，例如 google analytics、google optimize 或 Hotjar。
6. 技术债：该指标度量与软件质量或与此过程相关的任何其他活动相关的未决活动的数量。诸如审查生产中现有功能的未决覆盖率、增加自动化测试覆盖率、执行维护、重构、优化和自动化手动流程、审查测试、减少“不稳定测试”以及提高报告质量等活动。跟踪技术债务很重要，因为它会减慢软件开发的速度并增加缺陷和系统故障的可能性。
7. 代码审查：通过跟踪代码审查期间发现的问题数量，团队可以深入了解代码库的整体健康状况。问题数量较多可能表示需要引起注意的潜在质量问题。此外，对已识别问题的严重性进行分类可以让团队确定优先级并迅速解决关键问题。为了有效地跟踪代码审查反馈，团队可以使用工具或平台来促进审查过程并以结构化的方式捕获反馈。这允许有效的问题管理、后续行动和进度监控。
8. 非功能测试覆盖率：根据项目和产品，可以建立质量指标来度量此类测试的状态和演变、其合规性及其在程序中的采用情况。可以提及的指标包括：

生产事故管理指标

当然，针对线上事故也有多种指标用于度量事故解决流程的有效性。这些指标相互关联并梳理成特定的工作流程来处理事故，同时还测量每个阶段花费的时间并将其与预期结果进行比较。

为确保服务和应用程序具有可靠的性能，关注以下指标非常重要：

1. 平均检测时间 (MTTD)：这是发现问题所需的时间。通过最小化 MTTD，可以快速了解潜在问题并采取必要措施解决这些问题。
2. Mean Time to Acknowledge (MTTA)： MTTA 测量警报告警后操作所需的平均时间。MTTA 越短表示 IT 运维团队能快速响应并确保立即发现问题。
3. 平均响应时间 (MTTR)： MTTR 表示在确认服务问题后开始处理它所花费的平均时间。MTTR 越短意味着更快的响应速度。
4. 平均修复时间 (MTTR)：该指标度量从发现问题到解决问题所需的时间。MTTR 越短表示高效的故障排除和维修效率。
5. 平均解决时间 (MTTR)： MTTR 反映了完全解决问题和执行全面测试以确保相关系统正常运行所需的时间。
6. 平均恢复时间 (MTTR)： MTTR 表示将故障系统恢复到正常运行状态所需的时间。最大限度地减少 MTTR 有助于从故障中快速恢复正常的服务水平。

通过主动监控和优化这些指标，可以改善服务和应用程序的健康状况、可用性和可靠性。因此，可以更有效地实现任务目标并确保积极的用户体验。

度量质量文化指标

可以使用下面几个关键指标：成熟度级别、PROD中的事后分析事故以及 DevOps 和持续改进实践的。这些指标为组织的成熟度水平和维持质量标准的能力提供了宝贵的见解。

1. 成熟度级别：指的是一个组织或企业在软件测试方面的成熟度水平。成熟度级别通常使用 CMMI（Capability Maturity Model Integration）模型进行评估，CMMI 是一种用于评估和改进组织成熟度的模型。CMMI 模型将软件测试成熟度分为五个等级，从初始级别到优化级别依次为：

• • 初始级别（Level 1）：测试过程是无序的，没有规划，也没有可重复的方法。测试工作通常是由个人完成，缺乏标准化和自动化。
  • 可重复级别（Level 2）：测试过程已经开始规划和标准化，测试工作已经可重复，但仍然存在一些不规范和不一致的地方。
  • 定义级别（Level 3）：测试过程已经得到了更好的规划和标准化，测试工作已经得到了更好的控制和管理，测试工作已经得到了更好的跟踪和监控。
  • 管理级别（Level 4）：测试过程已经得到了更好的管理和优化，测试工作已经得到了更好的自动化和工具支持，测试工作已经得到了更好的度量和分析。
  • 优化级别（Level 5）：测试过程已经得到了最佳的优化和改进，测试工作已经得到了最佳的自动化和工具支持，测试工作已经得到了最佳的度量和分析，测试工作已经得到了最佳的持续改进。

1. PROD 中的事后分析事故：该指标度量生产环境中发生的事故的根本原因分析过程的有效性。它确保在功能、基础设施或质量测试级别采取纠正措施以防止再次发生。该过程涉及解决覆盖范围不足或特定测试类型的问题，对于保持产品质量至关重要。
2. 采用 DevOps 和持续改进实践：该指标度量组织采用 DevOps 实践的程度和持续改进的水平。它提供了自动化与手动流程的数量、持续集成水平、发布到生产的频率以及监控和可观察性水平的视图。持续改进对于保持高水平的产品质量和提高开发过程的效率至关重要。

SLA、SLI 和 SLO

建立和使用 SLA、SLI 和 SLO 等工具也很常见，以确保达到既定的质量标准和服务水平、设定明确的目标并专注于持续质量改进。

这些术语与上述指标结合使用以度量和提高质量。

服务级别协议 (SLA)：这是一份合同，用于确定将要提供的服务和必须满足的质量标准，在服务提供商和客户之间设定明确的期望。

服务水平指标 (SLI)：它是一种度量标准，用于度量服务是否符合 SLA 中定义的标准，度量服务在质量和服务水平方面的表现。通常使用实时监控和跟踪工具。

服务级别目标 (SLO)：这些用于确保满足 SLA 中定义的质量标准。

结论

质量指标的使用使公司能够提高其软件产品的质量、提高用户满意度并降低开发成本。通过在整个软件开发生命周期中仔细监控这些指标，团队可以查明需要改进的地方，度量质量目标的进展情况，并根据数据做出决策。对于软件开发团队而言，确定针对其特定项目、产品或质量目标量身定制的相关质量指标并将其无缝集成到质量管理流程中至关重要。通过这种方式，可以培养持续改进的文化并确保交付高质量的软件解决方案。