前言
接触越来越多的团队后，发现无论是QA人员的绩效考核、晋升，还是平时的交流，越来越少的人明确从整体来评估产品质量(ps:这里产品质量-包括需求质量，开发质量，测试质量，上线质量，运营质量等)的提升情况了，更别说测试质量的整体情况了。就拿QA人员来说，除了“天花乱坠”的说自己的自动化、持续集成、测试难题的解决等等话题外，很少从上帝的眼光，来评估整体测试质量的情况了。
写这篇博客，主要想讨论如何从全局考虑，通过哪些指标能更好的评估测试质量，进而能通过数据来反过来优化整体的测试方案。以下仅是自己的一些思考，未免有些不正确/不全之处，欢迎批评指正，多多交流！！！
评估测试质量时参考哪些指标
ps: 以下指标除了和测试质量有关外，当然也和开发质量，产品需求等等因素相关，但这里仅仅考虑其对测试质量的影响
线下bug的情况
- bug总数量变化趋势(每年/每季度/每月的变化)
- 严重级别及以上的bug总数量变化趋势(每年/每季度/每月的变化)
- 需求优化类bug情况(可以评估QA对产品的影响)
- 实现优化类bug情况(可以评估QA对技术实现的影响)
上线后的bug情况(即故障情况)
- 故障总数量变化趋势(每年/每季度/每月的变化)
- 严重故障的数量变化趋势(每年/每季度/每月的变化)
- 由于测试方案缺失导致的故障总数量变化趋势(每年/每季度/每月的变化)
不同深度测试方法测试场景覆盖及发现问题数
- 代码静态分析的执行情况(最好记录下静态分析后对问题的优化，并形成优化实践)
产出：代码静态分析优化规范、实践实例、优化的问题数量
- 单元测试的执行情况
产生：单元测试的用例数量、覆盖方法数量、发现的问题数量
- 模块测试的执行情况
产出：覆盖的模块比例、发现的问题数量
- 集成测试的执行情况
产出：覆盖的场景数量、涉及的具体测试方法(例如：功能、性能、兼容性、缓存...)
- 内测的执行情况
产出：内测的场景数量、参与的具体人员、发现的问题数量
测试类型/方法的多样性
- 针对业务特点，专门的测试类型/方法(例如，相比web，APP测试有固定的测试方法)
- 针对测试难点，采用的针对性的测试方法
- 为了更全面使得bug暴露，采用的其他种种方案
测试场景的维护情况
- 场景维护的前提一：稳定的测试环境
产出： 环境维护、环境使用方案，达到环境的有效利用
- 场景维护的前提二：数据
产出：不同环境数据的维护、动态数据的维护
- 场景维护的核心：如何不同创造/维护N种场景
产出：对场景的分析、数据的特点分析(比如动态数据)，维护效果(比如维护需要多久)
总结
总体来说，测试质量的评估，需要一段时间(年、季度、月、周)的数据来支撑。换句话说，无论是想证明测试质量的提升、还是测试质量的下降(当然了，很少有人愿意承认)，都需要拿具体的数据来进行证明。
细细想想，你负责的业务，是否有了这些质量数据了呢，如果没有、或者不全，也许已经说明了你的测试质量还有可提高之处。