一、缺陷率迷思
1.1 千行代码缺陷率被废弃
千行代码缺陷率 = Bug数量 / 千行代码数
这是一个经典指标，以前在研发侧经常用来衡量代码质量，近年被逐渐弃用。
原因是这个指标有负面的引导，似乎不鼓励写高质量的简洁代码，而稀释代码或造轮子则能带来比较好看的数据，这与指标设置的初衷“提升代码质量”相悖。
因此，该指标不建议横向比较，不建议作为绩效指标。但可以作为代码质量指导基线，或作为工程师的自我修养，用于自我评估和改进。
附上在CMMI里对千行代码缺陷率的标准，不难看出缺陷率还是以一个满足该等级的基线值存在的，也就是说它不能用来衡量代码质量有多好，但可以用来衡量代码质量最差不能低于什么水平。
1.2 缺陷率无法体现软件质量
缺陷率 = 失败的用例数 / 执行的用例总数
从字面意义上理解，这个指标看着像是衡量软件质量的。但放入研发体系内思考，通常在不同版本间，执行的用例总数是变化的，失败的用例数也取决于用例执行者的判断，而失败的用例又不一定会以缺陷的形式来跟踪。所以这个指标很难有确定的标准，那么它还是有意义的吗？
我认为是有意义的，意义在于它揭示了测试设计的质量，即经过设计的测试用例能否有效发现缺陷。从这个维度上讲，这个指标恐怕叫“用例有效率”更恰当一点。
不管是千行代码缺陷率，还是测试统计的缺陷率，统计时难免会陷入数据的迷思。片面追求数据好看，对团队的副作用很大，结果可能是既不经济、也没成效，平白做了很多无用功。思考质效工作如何经济又高效，有助于避开局部优化的泥沼。
二、质效管理投资回报
2.1 不是指标的锅，而是思路偏差
由上面的讨论容易得出以下结论：
- 第一，从度量引导团队改进的意义角度来看：指标数量绝对值 < 指标的环比（无任何时间间隔，连续周期内的变化），应更多关注团队指标的变化趋势，以及思考是什么原因引起的变化，该如何改进；
- 第二，团队内的任何投资，都需要考虑投入产出比 ROI，为了得到结果而付出巨大的代价，本身就是一种失效。尤其当资源被投入到“质效提升或管理”这类成本高见效慢的活动时，考虑是否经济尤为重要。
2.2 质效管理效率金字塔
为了获得更高的投资回报，不得不思考团队可能采取的投资和收益之间的关系，以及可能的影响因素：成本、反馈周期、效率等互相制约的程度。
（质效管理效率金字塔）
在软件研发活动中，有些事属于决定做什么和怎么做的定义范畴，如需求方案、技术架构、测试策略等；而有些事情属于落地实施范畴，如：工序拆解和研发、测试和运维。
当决定做研发治理时，在不同层次发力，所需成本、见效周期/观察期、治理效果也不尽相同。
- 在定义阶段发力，成本低、见效期长，但治理效果最好，问题根因也往往会追溯到此
在实施阶段发力，成本高、见效期短，但治理效率偏低，数据好看但治标不治本 - 因此，当我们追求不同的提升或治理目标时，所采取的策略也不尽相同。
假设团队处在新组建期，软件也处在MVP或0-1阶段，此时从底层思考比较好，在做前把问题定义清楚，架构和策略都想清楚，定义好后续实施阶段的各种门禁和标准，会为后续研发过程的顺利进行打造良好的基础。
假设团队较大，处于稳定期，软件也处在增强和维护期，软件的质量反馈出团队的潜在问题较多，此时比较短平快的方式是先抓实施层面，让团队快速看到效果，从而建立信心。通过实施层面反馈的问题，进一步根因分析，可能会发现在定义阶段需要进行测试策略的重塑。在团队调整的接受度和灵活性都较好时，再进行底层的改造，持续的观察和改进，就比较容易看到效果。
三、质效工作本质是打造高效高响应系统
3.1 系统是有机整体
系统是若干部分相互联系、相互作用，形成的具有某些功能的整体。系统动力学认为系统中的因、果回馈关系环环相扣，系统结构决定系统功能。举个例子，“三体”即为一个系统，在这个系统中，三个天体间的万有引力相互影响，相互制约，对外呈现一个动态系统。
在系统思考中，是以开了挂的全局眼光审视整个系统，而不仅仅是寻求局部最优解。雪崩时，没有一片雪花是无辜的，也没有一片雪花能够幸免。系统整体功能不好，牵涉其中的每个人都是受害者，也都是加害者。
因此在讨论系统时，我们既要研究系统中的各个组成元素，又要各元素之间相互影响的关系。
3.2 系统思考看待系统问题
为了更好的说明质效工作需要系统的看待问题，我们举一个常见的例子。在质量领域，有一个老生常谈的问题：自动化测试的投入产出比。由此衍生更多的问题：自动化测试难开展、难维护、难持续。以往在看待这个问题时，可能的思路是：测试人员的自动化能力较低，或者时间紧任务急没资源。
在采用系统思考看待这个问题时，就不会只是盯着测试人员做改进，而是思考整个研发系统在自动化测试上的瓶颈所在，追求的也是整个研发系统在自动化测试上面的投资回报率。
现在来推演一下，当要做决策时，我们追求高投资回报。而投资回报取决于成本和收益，成本越高投资回报率越低。那么，都有哪些因素影响自动化测试的成本呢？
影响自动化测试成本的因素：
- 软件本身的可测性：当软件可测性较低时，自动化成本就会飞升，甚至根本不具备可自动化的条件。而这个因素的可控性受制于软件的架构设计，在软件成熟期不具备可改进的灵活性。因此建议在做架构设计时就充分考虑软件可测性，否则后续的自动化测试会难以开展。
- 人员能力：这里不仅仅指自动化测试的编码能力，更要求测试人员具备一定的测试设计能力。能够充分理解测试分层，不同层的测试服务于什么目标，解决什么问题，以及测试的框架选型等能力。
- 资源配置：指团队的研发节奏，能否有余力进行充分的自动化测试。
- 环境依赖：自动化测试如果不能持续运行，就会失去尽早暴露缺陷的时机，而持续运行依赖于能排除干扰的稳定环境。
- 工具链割裂：指团队的工具链体系是否支持自动化测试持续集成，或者不同层级的自动化测试工具是否具备一致性。这在一定程度上影响自动化测试的可维护性。
3.3 质效工作的本质
基于以上的讨论，当思考如何提升自动化测试投资回报率时，我们就有了更多可能的改进方向。抽象一下，当思考质效工作本身时，我们需要打造的是一个高效高响应的系统。系统中包含各种元素：干系人、策略、实践、流程、资源、工具……各个元素之间又相互影响，相互制约。当需要作出决策时，充分分析系统中的各元素及其之间的关系，有助于我们得出全局优化方案。
下图为系统中涉及的元素集合：
接下来选取观察元素，思考相互关系，有机的组建一个系统。一个典型的系统思考应用就是冰玉老师的《一页纸测试策略》，如图：
基于这样一个决策系统，我们就很容易对齐质量领域下的预期和优先级，从而更好的促使团队进行改进。
而帮助团队设计和实施一个高效的、高响应力的质效系统，正是质效管理者的价值体现。
来源：圆小豆的美梦工场
作者：于晓南
声明：文章获得作者授权在IDCF社区公众号（devopshub）转发。优质内容共享给思否平台的技术同伴，如原作者有其他考虑请联系小编删除，致谢。
7月每周四晚8点，【冬哥有话说】研发效能工具专场，公众号留言“效能”可获取地址
- 7月8日，LEANSOFT-周文洋《微软DevOps工具链的 "爱恨情仇"（Azure DevOps）》
- 7月15日，阿里云智能高级产品专家-陈逊《复杂型研发协作模式下的效能提升实践》
- 7月22日，极狐(GitLab)解决⽅案架构师-张扬分享《基础设施即代码的⾃动化测试探索》
- 7月29日，字节跳动产品经理-胡贤彬分享《自动化测试，如何做到「攻防兼备」？》
- 8月5日，声网 AgoraCICD System负责人-王志分享《从0到1打造软件交付质量保证的闭环》