本周我们的讨论话题是关于测试质量管理：
讨论话题
- 问题：产品研发流程中有哪些质量数据？如何利用这些质量数据？
- 问题描述：在产品研发流程中，其实不仅仅有我们提的bug数量这一质量数据。还有很多可以衡量产品质量的数据纬度，比如：产品需求变更次数。
我们的最终目标是保障产品质量，提升产品质量的稳定性。因此，在你的工作中有统计哪些质量数据呢？是怎么利用这些质量数据的呢？
大家讨论分享的结果
本周只有一位同学参与讨论，不过我会详细阐明下我的观点。
某公司测试工程师—吕俊杰
其实个人不太建议单纯的使用bug数量或者严重bug数量作为质量好坏的依据甚至开发人员考核。如果真的要看，还是有些重要的指标的，就是bug reopen的次数，冒烟测试的通过率，bug修复的时间效率，上线后反馈bug，bug燃尽图(波峰时间，收敛时间，拐点等)。项目有大小，也要轻重缓急，项目和项目之间没什么好比较的，还是需要看在整个项目过程中，从立项到项目上线期间，这个流程是否合理，是否完成了每个阶段的里程碑。
不过他的观点主要还是围绕着bug，其实我觉得应该有更多的纬度。
我的观点
我觉得思考这个问题的出发点是产品质量，所有可能影响产品质量或者稳定性的因素都可以考虑进去。我觉得大致可以从以下几个方面考虑：
- 产品需求评审通过率：以产品feature为单位划分，计算每次需求评审通过率。从项目周期角度来看，产品需求评审不通过，会影响产品的正常研发效率。
- 产品需求变更次数：所有的开发和测试同学，最痛恨的应该就是需求改改改了吧？！每次需求变更，都需要重新评估开发和测试时间，会影响产品正常上线。统计这个数据，也能一定程度给产品经理思想压力，在设计需求时，做更多的考虑。
- 开发自测通过率：开发研发完成提测时，一定要统计它们自测通过情况。我们可以将测试用例中P0/P1级别的用例提供给开发，让他们进行自测。这个数据很重要，可以直接衡量开发的研发质量和工作态度。
- 【可选】开发单元测试覆盖率/通过率：如果你的公司，已经推行了单元测试，那么可以在提测打包时，获取单元测试的质量数据。当然这有个前提，开发的单元测试场景得足够充分，建议测试同学能查看开发的单元测试代码。
- 静态代码检测数据：这个实现成本挺低的，可以在Jenkins里做个持续集成项目，当开发提测时（一般是合代码到qa分支），自动触发进行代码扫描，将常见的问题（比如：空指针）提前暴漏出来。衡量指标可以是：不能有P0、P1级别的问题，P2、P3级别的问题不能超过多少个。
- bug整体数据：我个人觉得，bug给出一个整体的数据即可，比如：总共有多少个bug、遗留了多少个bug、reopen bug的数量、P0级别bug数量、P1级别bug数量。假如想统计每个开发同学的bug数据，我建议统计两个指标：P0级别bug数量（可以反映研发质量）、reopen bug数量（可以反映研发质量和工作态度）。
- 线上bug数量：产品上线后，要统计用户反馈的问题，是否有P0级别的致命问题出现。强烈建议组织产品质量复盘会，针对出现的问题，总结优化工作流程。
- 线上产品质量数据：这主要依赖各种监控平台，比如移动端产品一般有crash率统计工具bugly、服务端产品有质量监控报警平台或者接口自动化监控等，这些数据可以作为产品质量的一个衡量纬度。
总结
上面列了一些质量数据可以参考的点，可能不全。大家如果有其他的建议，可以跟我联系，我再补充。
总之，我建议大家在平时的工作中，要善于利用各种质量数据，一来可以为我们的软件测试工作服务；二来这个数据一定程度可以提升测试在团队中的地位。