讨论来自一个社区朋友。
小A：“晓南老师，我带着问题来了。通常测试报告中【缺陷率】这个指标，我们有没有参考的指标，比如某个模块缺陷率为多少合适，还是说这个模块跟以往的build进行环比呢？”
晓南：“横向对比指标绝对值没啥太大意义，变化趋势比较有意义，所以推荐跟这个模块历史数据对比。因为不同模块业务不同，复杂度也不同。”
小A：“也就是说，第一个版本的缺陷率拿出来，跟其他项目进行比较的结果没有实际的参考意义；我也更加认同看趋势，做环比。”
晓南：“是的，环比更有意义，横向对比基本没啥意义。或者这么说吧，横向比较只能定基线值，最差不能低于多少，至于达标后的各自高低，就没有可比性了。”
小A：“这句话好像解决了我的疑惑。”
晓南：“嗯，不能说绝对没意义，如果有一点意义的话，那就是定基准了。”
小A：“原来是有点动摇的想法，现在更加清楚了；通常来说这个基线值如何定制，是有行业的规范还是公司内部的标准？我好像查不到这方面的资料，只有CMMI的一个千行代码标准。”
晓南：“没有行业规范，各个公司可能不太一样，根据自己的研发能力定基线就行了。我们可以选取研发胜任力相对平均的团队值作为基线参考。”
小A：“听君一席话，胜读十年书。”
缺陷率迷思
千行代码缺陷率被废弃
千行代码缺陷率 = Bug数量 / 千行代码数
这是一个经典指标，以前在研发侧经常用来衡量代码质量，近年被逐渐弃用。
原因是这个指标有负面的引导，似乎不鼓励写高质量的简洁代码，而稀释代码或造轮子则能带来比较好看的数据，这与指标设置的初衷“提升代码质量”相悖。
因此，该指标不建议横向比较，不建议作为绩效指标。但可以作为代码质量指导基线，或作为工程师的自我修养，用于自我评估和改进。
附上在CMMI里对千行代码缺陷率的标准，不难看出缺陷率还是以一个满足该等级的基线值存在的，也就是说它不能用来衡量代码质量有多好，但可以用来衡量代码质量最差不能低于什么水平。
缺陷率无法体现软件质量
<div style="text-align:center">缺陷率 = 失败的用例数 / 执行的用例总数
</div>
从字面意义上理解，这个指标看着像是衡量软件质量的。但放入研发体系内思考，通常在不同版本间，执行的用例总数是变化的，失败的用例数也取决于用例执行者的判断，而失败的用例又不一定会以缺陷的形式来跟踪。所以这个指标很难有确定的标准，那么它还是有意义的吗？
我认为是有意义的，意义在于它揭示了测试设计的质量，即经过设计的测试用例能否有效发现缺陷。 从这个维度上讲，这个指标恐怕叫“用例有效率”更恰当一点。
不管是千行代码缺陷率，还是测试统计的缺陷率，统计时难免会陷入数据的迷思。片面追求数据好看，对团队的副作用很大，结果可能是既不经济、也没成效，平白做了很多无用功。思考质效工作如何经济又高效，有助于避开局部优化的泥沼。
质效管理投资回报
不是指标的锅，而是思路偏差
由上面的讨论容易得出以下结论：
第一，从度量引导团队改进的意义角度来看：指标数量绝对值 < 指标的环比（无任何时间间隔，连续周期内的变化），应更多关注团队指标的变化趋势，以及思考是什么原因引起的变化，该如何改进；
第二，团队内的任何投资，都需要考虑投入产出比 ROI，为了得到结果而付出巨大的代价，本身就是一种失效。 尤其当资源被投入到“质效提升或管理”这类成本高见效慢的活动时，考虑是否经济尤为重要。
质效管理效率金字塔
为了获得更高的投资回报，不得不思考团队可能采取的投资和收益之间的关系，以及可能的影响因素：成本、反馈周期、效率等互相制约的程度。
在软件研发活动中，有些事属于决定做什么和怎么做的定义范畴，如需求方案、技术架构、测试策略等；而有些事情属于落地实施范畴，如：工序拆解和研发、测试和运维。
当决定做研发治理时，在不同层次发力，所需成本、见效周期/观察期、治理效果也不尽相同。
- 在定义阶段发力，成本低、见效期长，但治理效果最好，问题根因也往往会追溯到此
- 在实施阶段发力，成本高、见效期短，但治理效率偏低，数据好看但治标不治本
因此，当我们追求不同的提升或治理目标时，所采取的策略也应做不同的组合。
假设团队处在新组建期，软件也处在MVP或0-1阶段，此时从底层思考比较好，在做前把问题定义清楚，架构和策略都想清楚，定义好后续实施阶段的各种门禁和标准，会为后续研发过程的顺利进行打造良好的基础。
假设团队较大，处于稳定期，软件也处在增强和维护期，软件的质量反馈出团队的潜在问题较多，此时比较短平快的方式是先抓实施层面，让团队快速看到效果，从而建立信心。通过实施层面反馈的问题，进一步根因分析，可能会发现在定义阶段需要进行测试策略的重塑。在团队调整的接受度和灵活性都较好时，再进行底层的改造，持续的观察和改进，就比较容易看到效果。
质效工作本质是打造高效高响应系统
系统是有机整体
系统是若干部分相互联系、相互作用，形成的具有某些功能的整体。系统动力学认为系统中的因、果回馈关系环环相扣，系统结构决定系统功能。 举个例子，“三体”即为一个系统，在这个系统中，三个天体间的万有引力相互影响，相互制约，对外呈现一个动态系统。
在系统思考中，是以开了挂的全局眼光审视整个系统，而不仅仅是寻求局部最优解。雪崩时，没有一片雪花是无辜的，也没有一片雪花能够幸免。系统整体功能不好，牵涉其中的每个人都是受害者，也都是加害者。
因此在讨论系统时，我们既要研究系统中的各个组成元素，又要各元素之间相互影响的关系。
系统思考看待系统问题
为了更好的说明质效工作需要系统的看待问题，我们举一个常见的例子。在质量领域，有一个老生常谈的问题：自动化测试的投入产出比。由此衍生更多的问题：自动化测试难开展、难维护、难持续。以往在看待这个问题时，可能的思路是：测试人员的自动化能力较低，或者时间紧任务急没资源。
在采用系统思考看待这个问题时，就不会只是盯着测试人员做改进，而是思考整个研发系统在自动化测试上的瓶颈所在，追求的也是整个研发系统在自动化测试上面的投资回报率。
现在来推演一下，当要做决策时，我们追求高投资回报。而投资回报取决于成本和收益，成本越高投资回报率越低。那么，都有哪些因素影响自动化测试的成本呢？
影响自动化测试成本的因素：
1. 软件本身的可测性： 当软件可测性较低时，自动化成本就会飞升，甚至根本不具备可自动化的条件。而这个因素的可控性受制于软件的架构设计，在软件成熟期不具备可改进的灵活性。因此建议在做架构设计时就充分考虑软件可测性，否则后续的自动化测试会难以开展。
2. 人员能力： 这里不仅仅指自动化测试的编码能力，更要求测试人员具备一定的测试设计能力。能够充分理解测试分层，不同层的测试服务于什么目标，解决什么问题，以及测试的框架选型等能力。
3. 资源配置： 指团队的研发节奏，能否有余力进行充分的自动化测试。
4. 环境依赖： 自动化测试如果不能持续运行，就会失去尽早暴露缺陷的时机，而持续运行依赖于能排除干扰的稳定环境。
5. 工具链割裂： 指团队的工具链体系是否支持自动化测试持续集成，或者不同层级的自动化测试工具是否具备一致性。这在一定程度上影响自动化测试的可维护性。
质效工作的本质
基于以上的讨论，当思考如何提升自动化测试投资回报率时，我们就有了更多可能的改进方向。抽象一下，当思考质效工作本身时，我们需要打造的是一个高效高响应的系统。 系统中包含各种元素：干系人、策略、实践、流程、资源、工具……各个元素之间又相互影响，相互制约。当需要作出决策时，充分分析系统中的各元素及其之间的关系，有助于我们得出全局优化方案。
下图为系统中涉及的元素集合：
接下来选取观察元素，思考相互关系，有机的组建一个系统。一个典型的系统思考应用就是冰玉老师的《一页纸测试策略》，如图：
基于这样一个决策系统，我们就很容易对齐质量领域下的预期和优先级，从而更好的促使团队进行改进。
而帮助团队设计和实施一个高效的、高响应力的质效系统，正是质效管理者的价值体现。
推荐阅读：
