软件质量度量

软件质量度量

软件度量 (Software metrics) 是用于理解、管理和改进软件产品、过程和项目的量化指标。选择与特定目标一致的正确度量指标（回顾 GQM 方法）对于推动有意义的改进至关重要。

度量指标大致可分为：

• 产品度量：描述软件本身的特性（例如，规模、复杂度、可靠性、性能）。
• 过程度量：衡量开发、测试和维护过程的特性（例如，效率、有效性、对标准的遵守）。
• 项目度量：描述项目属性和执行情况（例如，成本、进度、工作量、团队生产力）。

软件质量度量 (Software quality metrics) 专门关注与产品质量属性以及过程实现质量的有效性相关的方面。它们通常在产品度量和过程度量类别之间存在重叠。

软件质量度量的关键类别包括：

• 代码质量度量
• 测试质量度量
• 过程效率与流程度量
• 运营与可靠性度量
• 客户满意度度量
• 维护质量度量

代码质量度量

这些度量指标评估源代码的内部质量，通常是可维护性、可靠性和安全性的先行指标。

• 圈复杂度 (Cyclomatic Complexity)：衡量控制流的复杂度。高复杂度通常与较高的缺陷率以及测试/理解难度相关。
• 认知复杂度 (Cognitive Complexity)：旨在衡量代码对人类而言有多难理解。
• 代码重复率 (Code Duplication)：代码重复的百分比。高重复率会增加维护工作量和风险。
• 可维护性指数 (Maintainability Index)：一个综合评分（通常在 0-100 之间），由复杂度、代码行数 (LOC) 和 Halstead 工作量等度量指标计算得出（具体公式各异）。分数越高表明可维护性越好。
• 代码变动频率 (Code Churn)：代码片段被修改的频率。高变动频率可能表明不稳定或存在问题。
• 静态分析违规项 (Static Analysis Violations)：静态分析工具发现的问题数量（例如，潜在 Bug、安全漏洞、代码风格违规）。跟踪趋势很重要。

测试质量度量

这些度量指标评估测试活动的有效性和效率。

• 测试覆盖率 (Test Coverage)：由自动化测试执行的代码（行、分支、方法）百分比（单元测试 Unit Test、集成测试 Integration Test）。提供了对测试套件彻底性的洞察，但不保证测试质量。
• 缺陷密度（测试期间）(Defect Density)：在正式测试阶段，每单位规模（千行代码 KLOC、功能点 Function Points）发现的缺陷数量。用于比较不同版本或组件。
• 缺陷发现率 (Defect Detection Percentage, DDP) / 阶段遏制率 (Phase Containment)：在特定阶段（例如，单元测试）发现的缺陷数量占该代码后续发现的总缺陷数量的百分比。
• 测试执行状态：已执行、通过、失败、阻塞的计划测试数量/百分比。
• 自动化测试与手动测试工作量比：在自动化和手动测试活动上花费的工作量之比。

过程效率与流程度量

这些度量指标通常与敏捷 (Agile) 和 DevOps 相关，衡量开发和交付过程的速度和效率。

• 前置时间 (Lead Time)：从需求被确定/接受到其交付至生产环境的时间。
• 周期时间 (Cycle Time)：从开始处理一个事项到完成（例如，从“进行中”到“完成”）的时间。
• 部署频率 (Deployment Frequency)：代码成功部署到生产环境的频率。频率越高通常表明过程越成熟。
• 变更失败率 (Change Failure Rate)：导致生产环境故障需要修复（例如，回滚、热补丁 hotfix）的部署百分比。一个关键的 DORA 指标。
• 平均恢复时间 (Mean Time To Recover, MTTR)：生产环境故障后恢复服务的平均时间。另一个关键的 DORA 指标。

运营与可靠性度量

这些度量指标衡量软件在生产环境中运行后的质量。

• 平均故障间隔时间 (Mean Time Between Failures, MTBF)：系统故障之间的平均时间。主要用于硬件，但也概念性地应用于关键软件系统。
• 平均无故障时间 (Mean Time To Failure, MTTF)：一个不可修复的系统（或组件）在发生故障前平均运行的时间。
• 可用性 (Availability)：系统运行并可供用户使用的时间百分比（例如，99.9%，俗称“三个九”）。
• 应用性能度量：在不同负载条件下的响应时间、吞吐量、错误率、资源利用率 (CPU, memory)。
• 生产环境缺陷密度：发布后用户报告的缺陷数量，通常按用户基数或使用时长进行归一化。

客户满意度度量

这些度量指标衡量用户对软件质量和价值的感知。

• 客户满意度评分 (Customer Satisfaction Score, CSAT)：通过调查衡量，通常使用量表（例如 1-5 分，从非常不满意到非常满意）。派生指标包括“满意度百分比”、“不满意度百分比”。
• 净推荐值 (Net Promoter Score, NPS)：基于问题“您有多大可能向他人推荐本产品/服务？”来衡量客户忠诚度。
• 客户费力度评分 (Customer Effort Score, CES)：衡量客户在使用产品/服务时感到有多容易。
• 任务成功率：使用软件成功完成特定任务的用户百分比（通常在可用性测试中衡量）。
• 客户支持工单：报告给支持渠道的问题数量和严重程度。

客户问题度量 (Customer Problems Metric, PUM - 历史背景)：这是一个衡量每用户月总问题数（包括缺陷和非缺陷问题）的指标。公式如下：

PUM = Total Customer Reported Problems / Total License Months

虽然跟踪客户问题的概念至关重要，但与 CSAT、NPS 以及支持工单的原始数量/严重程度等指标相比，PUM 本身现在已较少使用。

维护质量度量

在维护阶段，重点转移到高效且有效地解决报告的问题。

• 修复积压 (Fix Backlog)：未解决/待处理的报告缺陷数量，通常按时间跟踪。
• 积压管理指数 (Backlog Management Index, BMI)：一个周期内已关闭问题数量与新报告问题数量之比。$$BMI = (Number : of : problems : closed / Number : of : problems : arrived) \times 100%$$ BMI > 100 表示积压量正在减少。
• 平均解决时间（针对缺陷）(Mean Time to Resolution, MTTR)：从缺陷报告到修复部署的平均时间。
• 修复响应时间：从缺陷报告到初步响应或确认的平均时间。
• 逾期修复百分比 (Percent Delinquent Fixes)：超出约定解决时间（通常基于严重程度）的修复所占百分比。$$Percent :Delinquent = (Number : of : overdue : fixes / Total : fixes : delivered) \times 100%$$
• 修复质量 / 错误修复率 (Bad Fix Rate)：不正确（未解决问题）或引入新回归问题 (regression) 的修复所占百分比。目标应接近 0%。

有效的质量管理依赖于从这些类别中选择一组均衡的度量指标，对其进行可视化（例如，通过仪表盘 dashboards），并利用它们来推动有针对性的改进。