从缺陷率到质效工作的本质

来源：圆小豆的美梦工场作者：于晓南

讨论来自一个社区朋友。

一、缺陷率迷思

1.1 千行代码缺陷率被废弃

千行代码缺陷率 = Bug数量 / 千行代码数

这是一个经典指标，以前在研发侧经常用来衡量代码质量，本质近年被逐渐弃用。从缺

原因是陷率效工这个指标有负面的引导，似乎不鼓励写高质量的到质简洁代码，而稀释代码或造轮子则能带来比较好看的本质数据，这与指标设置的从缺初衷“提升代码质量”相悖。

因此，陷率效工该指标不建议横向比较，到质不建议作为绩效指标。本质但可以作为代码质量指导基线，从缺或作为工程师的陷率效工自我修养，用于自我评估和改进。到质

附上在CMMI里对千行代码缺陷率的标准，不难看出缺陷率还是以一个满足该等级的基线值存在的，也就是说它不能用来衡量代码质量有多好，但可以用来衡量代码质量最差不能低于什么水平。

1.2 缺陷率无法体现软件质量

缺陷率 = 失败的用例数 / 执行的云南idc服务商用例总数

从字面意义上理解，这个指标看着像是衡量软件质量的。但放入研发体系内思考，通常在不同版本间，执行的用例总数是变化的，失败的用例数也取决于用例执行者的判断，而失败的用例又不一定会以缺陷的形式来跟踪。所以这个指标很难有确定的标准，那么它还是有意义的吗？

我认为是有意义的，意义在于它揭示了测试设计的质量，即经过设计的测试用例能否有效发现缺陷。从这个维度上讲，这个指标恐怕叫“用例有效率”更恰当一点。

不管是千行代码缺陷率，还是测试统计的服务器托管缺陷率，统计时难免会陷入数据的迷思。片面追求数据好看，对团队的副作用很大，结果可能是既不经济、也没成效，平白做了很多无用功。思考质效工作如何经济又高效，有助于避开局部优化的泥沼。

二、质效管理投资回报

2.1 不是指标的锅，而是思路偏差

由上面的讨论容易得出以下结论：

第一，从度量引导团队改进的意义角度来看：指标数量绝对值 < 指标的环比（无任何时间间隔，连续周期内的变化），应更多关注团队指标的变化趋势，以及思考是什么原因引起的变化，该如何改进；第二，团队内的任何投资，香港云服务器都需要考虑投入产出比 ROI，为了得到结果而付出巨大的代价，本身就是一种失效。尤其当资源被投入到“质效提升或管理”这类成本高见效慢的活动时，考虑是否经济尤为重要。2.2 质效管理效率金字塔为了获得更高的投资回报，不得不思考团队可能采取的投资和收益之间的关系，以及可能的影响因素：成本、反馈周期、效率等互相制约的程度。（质效管理效率金字塔）在软件研发活动中，有些事属于决定做什么和怎么做的定义范畴，如需求方案、技术架构、测试策略等；而有些事情属于落地实施范畴，如：工序拆解和研发、测试和运维。当决定做研发治理时，在不同层次发力，所需成本、见效周期/观察期、治理效果也不尽相同。在定义阶段发力，成本低、见效期长，但治理效果最好，问题根因也往往会追溯到此； 在实施阶段发力，成本高、见效期短，但治理效率偏低，数据好看但治标不治本。因此，当我们追求不同的提升或治理目标时，所采取的策略也不尽相同。假设团队处在新组建期，软件也处在MVP或0-1阶段，此时从底层思考比较好，在做前把问题定义清楚，架构和策略都想清楚，定义好后续实施阶段的各种门禁和标准，会为后续研发过程的顺利进行打造良好的基础。假设团队较大，处于稳定期，软件也处在增强和维护期，软件的质量反馈出团队的潜在问题较多，此时比较短平快的方式是先抓实施层面，让团队快速看到效果，从而建立信心。通过实施层面反馈的问题，进一步根因分析，可能会发现在定义阶段需要进行测试策略的重塑。在团队调整的接受度和灵活性都较好时，再进行底层的改造，持续的观察和改进，就比较容易看到效果。

三、质效工作本质是打造高效高响应系统

3.1 系统是有机整体系统是若干部分相互联系、相互作用，形成的具有某些功能的整体。系统动力学认为系统中的因、果回馈关系环环相扣，系统结构决定系统功能。举个例子，“三体”即为一个系统，在这个系统中，三个天体间的万有引力相互影响，相互制约，对外呈现一个动态系统。在系统思考中，是以开了挂的全局眼光审视整个系统，而不仅仅是寻求局部最优解。雪崩时，没有一片雪花是无辜的，也没有一片雪花能够幸免。系统整体功能不好，牵涉其中的每个人都是受害者，也都是加害者。因此在讨论系统时，我们既要研究系统中的各个组成元素，又要各元素之间相互影响的关系。3.2 系统思考看待系统问题为了更好地说明质效工作需要系统的看待问题，我们举一个常见的例子。在质量领域，有一个老生常谈的问题：自动化测试的投入产出比。由此衍生更多的问题：自动化测试难开展、难维护、难持续。以往在看待这个问题时，可能的思路是：测试人员的自动化能力较低，或者时间紧任务急没资源。在采用系统思考看待这个问题时，就不会只是盯着测试人员做改进，而是思考整个研发系统在自动化测试上的瓶颈所在，追求的也是整个研发系统在自动化测试上面的投资回报率。现在来推演一下，当要做决策时，我们追求高投资回报。而投资回报取决于成本和收益，成本越高投资回报率越低。那么，都有哪些因素影响自动化测试的成本呢？ 影响自动化测试成本的因素：软件本身的可测性：当软件可测性较低时，自动化成本就会飞升，甚至根本不具备可自动化的条件。而这个因素的可控性受制于软件的架构设计，在软件成熟期不具备可改进的灵活性。因此建议在做架构设计时就充分考虑软件可测性，否则后续的自动化测试会难以开展。人员能力：这里不仅仅指自动化测试的编码能力，更要求测试人员具备一定的测试设计能力。能够充分理解测试分层，不同层的测试服务于什么目标，解决什么问题，以及测试的框架选型等能力。资源配置：指团队的研发节奏，能否有余力进行充分的自动化测试。环境依赖：自动化测试如果不能持续运行，就会失去尽早暴露缺陷的时机，而持续运行依赖于能排除干扰的稳定环境。工具链割裂：指团队的工具链体系是否支持自动化测试持续集成，或者不同层级的自动化测试工具是否具备一致性。这在一定程度上影响自动化测试的可维护性。3.3 质效工作的本质基于以上的讨论，当思考如何提升自动化测试投资回报率时，我们就有了更多可能的改进方向。抽象一下，当思考质效工作本身时，我们需要打造的是一个高效高响应的系统。系统中包含各种元素：干系人、策略、实践、流程、资源、工具……各个元素之间又相互影响，相互制约。当需要作出决策时，充分分析系统中的各元素及其之间的关系，有助于我们得出全局优化方案。下图为系统中涉及的元素集合：接下来选取观察元素，思考相互关系，有机的组建一个系统。一个典型的系统思考应用就是冰玉老师的《一页纸测试策略》，如图：基于这样一个决策系统，我们就很容易对齐质量领域下的预期和优先级，从而更好的促使团队进行改进。而帮助团队设计和实施一个高效的、高响应力的质效系统，正是质效管理者的价值体现。

很赞哦!（65）