一、质量度量需求
1、QA人员角度
- 规范化管理需求。不同业务线之间，尽管业务特点不同，但都遵守需求、实现、测试、上线这么一个过程。如何评估当前迭代中的每个节点执行的质量。
- 流程/规范优化效果评估。通常为了支撑迭代要求、质量要求，并使团队成员更高效的合作，通常会主动/被动形成各种项目流程。这些流程大致分为：
1）业务线级别共同的流程。比如提测流程、上线流程、迭代周期等，各个业务线都有这些，不同的是具体的细节操作了
2）某些业务线特有的流程。比如：线下的产品内测、流量较大的业务会增加核心监控检查、改动较大的业务通常会增加预发布环节
但是，不同的业务线需要不同执行形式的流程，无法直观的判断某业务到底是否应该添加某个流程，或者优化了某个流程后，究竟给后续迭代带来了哪些好处和坏处呢
- 上线风险控制。为了防止上线后直接导致线上故障，通常会在真正上线前，采取一些措施，来适当减少发生故障的风险，具体措施包括：预发布、灰度发布、单服务增量测试增量上线等。那么，究竟如何评估这些措施给风险控制带来的价值呢
- 数据支撑质量收益。线上真真正正发生的故障，根本原因到底是什么，采取了相应措施后，能否有数据支撑带来的质量收益呢
- 质量保证奖励。如何评估开发人员、产品人员在整个质量保证过程中起到的作用，以及具备良好质量意识的人员以奖励
2、业务团队其他成员角度
- 质量风险评估。测试来测试去，是否还有质量风险/盲区
- 优化流程的意义评估。开发人员的心理活动：QA人员老是优化这个流程、增加那个流程，增加了不少工作，感觉不是太必要啊
- 质量控制的参与度。产品人员、开发人员普遍认识是：质量控制靠QA人员，参与多少无所谓，出了问题，就是QA人员没有测试到
3、 质量管理角度
- 新同学加入，无缝完成对接。这里涉及质量的传承问题，如何让新人很快的“吸收到”之前的经验，并游刃有余的使用
- 业务线质量成熟度评估。这里涉及当前的测试体系建设的成熟度，一段时间内，成熟度提高了多少
- 资“质”通鉴。这里的“质”指产品的质量。这里的鉴包括两个方面：
1）一条产品线通常情况下，迭代需求、业务特点、测试难点、团队成员合作模式不会发生太大的变化，因而从过去的抗里，可以看出现在、未来可以做的更好的点；
2）不同的产品线之间，成熟的产品线往往在基础设施、经验积累、质量体系成熟度等方面都有不错的积累，新起不久的产品线，可以从成熟产品线借鉴经验、模式，快速打造相对比较成熟的质量体系
二、质量数据指标
1、迭代中各个节点数据
- 整个迭代。 预计周期、实际迭代周期等，得到排期delay情况
- 需求。需求的完整性、需求评审后变动情况、需求评审中的优化点(具体提出人)
- 技术评审。评审中得出的具体测试点, 技术优化点(具体提出人)
- 测试用例评审。得出的具体测试优化点(具体提出人)
- 测试。需求类问题数量、技术优化类问题数量、体验优化类问题数量、第三方问题数量、内测发现问题数量(具体提出人)
- 预上线/灰度。发现问题数量
- 上线后效果。是否回滚；上线后问题数量，严重级别
2、迭代过程评估数据
- bug情况。bug总数、一段时间趋势、严重比
- 提测情况。主流程是否通
- 上线过程是否顺利，上线顺利程度=评估上线步骤准备
- 上线后效果是否符合预期。回滚率，线上问题数量=评估测试覆盖，技术评审的改动影响点评估粒度
3、监控数据
- 线上发现问题数量、级别；
- 失败率趋势；
- 第三方问题数量；
4、周期性数据
- 迭代周期变化
- bug数量变化
- 内测参与度变化