背景
目前业界并没有通用的、可参考性的软件质量评判标准，经常有客户期望我们能提供评判标准，但是实际上我们自己也没有一套可复制的标准。
以缺陷或者用例的数量、代码行数、甚至各种比率，仅仅起到数据展示，想要整合之后出具质量报告，其实是需要大量的管理经验才能够总结的。
这就造成了市场上虽然有很多管理工具，但很多团队或者企业仍然无法总结软件质量。
以下是期望通过一种标准化的综合性评级系统，解决市场上缺乏质量管理总结经验的问题。
评级体系的设想
- 利用现有的业界通用软件质量指标，设计评级系统「评级类似于SonarQube」
- 把从业经验转换为可量化、可对比的推荐评级
- 最终聚合所有指标评级，按照权重综合评级如: S、A、B、C、D
- 以此作为软件质量的评判标准
目前业界通用指标
由于单纯数量并没有可比性和传承性，因此以下指标均采用比率的方式：
| 指标 | 计算方法 |
|---|---|
| 缺陷密度 | bugs ÷ code lines * 1000 |
| 回归缺陷率 | regression bugs ÷ total bugs * 100% |
| 二次缺陷率 | reopen bugs ÷ total bugs * 100% |
| 缺陷探测率 | qa found bugs ÷ ( qa found bugs + customer found bugs ) * 100% |
| 缺陷修复率 | fixed bugs ÷ total bugs * 100% |
| 缺陷验证率 | verified bugs ÷ fixed bugs * 100% |
| 测试执行率 | executed cases ÷ total cases * 100% |
| 测试通过率 | pass cases ÷ executed cases * 100% |
度量维度
根据个人近10年从业经验来看，这些指标的推荐总结维度如下:
- 产品/项目维度
- 不同版本(Sprint/迭代)间的比较，以观察产品不同版本的品质反馈
- Sprint/迭代维度
- 周期内除了以上各种指标外，还可以增加速率指标，以观察是否存在项目管理上的风险
- 不同新功能之间的比较，以识别出品质风险较大的功能模块
- 不同缺陷类别之间的比较，以识别出本轮迭代的风险来源
- 不同轮次/RC(RC=Release Candidate)之间的比较，以观察其趋势是否符合周期内的研发工作
评级体系的指标制定
指标计算表
评级体系的落地
要想落地这么一套体系，需要完成以下工作:
- 数据采集
- 指标计算
- 评级汇总
篇幅有限，文中一定还有不严谨之处，待日后不断完善。
