质量内建漫谈-分享有感

[Hi-CodeCaptain]

作者：翁新锋 Hi-Agile资深技术教练、十余年全栈开发

一、缺陷的暴露与预防

著名质量管理专家戴明提到：“质量没法检测出来，软件产品开发出来后质量就已经确定。”

也就是说，质量是产品与生俱来的，我们可以说，一旦产品开发完成，该软件存在缺陷的总量是一定的。如果总量的缺陷中有一部分可以通过某些措施来预防，那么软件在测试或最终用户使用过程中所暴露出来的缺陷数量就会减少，这就是缺陷预防——减少测试或使用中暴露的缺陷。

缺陷总量一定，那么能提前预防的缺陷越多，则最终在使用时暴露出来的缺陷则越少，软件的质量也越高。软件开发是个历经多个环节的持续过程，提前预防缺陷意味着需要提前发现并修复缺陷，要做到这一点需要在软件进入测试前进行持续的、相应的工作。

二、缺陷的修复成本

下图相信很多人都见过，它揭示了软件缺陷在不同阶段的表现情况。可以看到，大部分缺陷都是早期引入的，同时大部分缺陷都是中晚期发现的，而缺陷发现的越晚，其修复成本将急剧上涨。

下图来源：Applied Software Measuremnet. Capers Jones. 1996引用

由此可见，缺陷越早发现并着手修复，将会大大降低修复成本。正因为如此，软件研发的质量保障工作最为有效的做法是将质量控制活动落实到生产的各个环节中去，而不是通过后期的集中测试和修复，也就是说，要将质量构建到软件产品本身，提高软件产品自身的质量属性，这也就是质量内建（Built-in Quality）。

三、质量内建的四大核心

质量内建作用在开发过程中， 要求软件生命周期之间参与的各个角色都需要实时的对软件的质量负责。 确保软件在交付到下一环节前已经有一定的质量保证。质量内建的过程就是把质量控制向源头不断推进的过程，让预防缺陷替代暴露缺陷。

整体来说，质量内建的核心可以总结为一句话：尽早自验，及时反馈，共建质量，不再只让测试做质量兜底。扩展开来讲以四个方面为主：

1. 测试左移

传统软件开发会分成分析、设计、开发、测试、发布等几个相对独立的阶段，而测试是其中发生在开发编码完成之后的一个阶段。

测试左移相对来说不再强调独立的测试阶段，而是要将测试活动左移到软件开发生命周期的最早阶段（最左边）——需求阶段，从需求阶段开始做好缺陷预防的工作。

按照质量内建的原则来说，理想情况下肯定是左移越早越好，但如果一时做不到彻底左移，能尽量前移一步也是进步。因此测试活动左移到独立测试阶段左侧进行，我们认为就是左移，并不是必须一步到位要左移到需求阶段。毕竟质量内建不是一蹴而就的事情。

另外，很多人对测试左移有误解，认为左移就是测试人员的事，让测试人员提前介入，在测试前阶段进行部分工作（例如用例设计，需求对齐等）就是左移。事实上，我们强调的不仅仅是测试人员的左移，而应该是测试活动的左移。

• 测试人员的确需要左移参与相应的活动。但是，如果测试人员参与需求阶段，只是为了被动接收需求信息，却没有起到澄清需求、验证需求有效性的作用，那就不是有效的测试左移，关键要看成效。
• 不仅测试人员要左移，开发等其他角色也需要左移。因为需求有效性的验证，需要不同角色的经验，需要来自不同视角的输入；不同角色都有责任参与到每个环节的测试活动中来。
• 各个阶段都有相应的测试活动，并非特指测试人员。这里强调的是测试活动，到底谁来做并不是最关键的。比如有的团队是没有测试人员的，但不代表这些团队没有测试活动。这里就要求需求的分析、设计、开发人员对自身的交付品进行最大限度的自我测试，在此过程中可以与测试人员多沟通，得到来自专业测试人员的帮助。

总结来说，测试左移既包含了角色的左移（例如开发、测试都提前参与需求的澄清验证），也包含了测试活动的左移（例如开发人员本身进行自我测试）。

2. 快速反馈

快速反馈，也就是频繁持续地反馈，可以理解为一个持续测试的过程。

我们希望缺陷产生后能够快速被捕捉到，并反馈给相关人员。为了减少这个反馈的等待时间，通常需要有自动化的支撑，比如自动化测试、流水线上自动代码扫描等；也可以是一些人工参与的实践环节，比如手动测试、各类评审和验收等。通过这样的一些实践活动尽快地获取相应工作（可能是需求分析、开发等）的反馈，根据反馈结果进行及时的修复、调整、或者优化。

为了保障快速反馈/持续测试实践活动的有效开展，通常需要增加质量门禁，并确保质量门禁的严格执行。这样可以保证问题能被第一时间拦截并反馈到相应人员。

3. 测试右移

测试右移跟测试左移对应，就是将测试活动从独立测试阶段右移到生产环境。

但因为生产环境的特殊性，测试右移又不是测试活动的简单右移，而是通过一些实践活动获取生产环境下用户行为、日志等质量相关信息，利用这些信息来给前期的需求、开发和测试工作提供反馈，促进相应工作的优化改进。

总结来说就是根据产品的实际运行情况，进行相关信息的归并分析，从而指导整个开发进行预料之外的问题预防。

测试右移在本次交付中无法直接内建质量，但是可以帮助团队后续进行更好地缺陷预防，促进质量内建。

4. 全员参与

测试左移、快速反馈和测试右移都不是某个单一角色/人员可以做到的，需要不同角色的不同技能和不同视角的输入，质量人人有责，需要全员参与并且能承担起质量职责才行。

软件产品质量是一个系统工程，任何一个环节出现问题都会对产品质量造成影响，为保证没有问题，最终一定会有人替这个环节负重。只要有别人替你负重，就会增加更多的成本，比如额外的确认、沟通、理解原始思路等。达到相同的质量水准，付出成本高，将会被成本低的所取代。最终取代你的一定是全员参与的。因为这样成本最低。

四、质量内建推荐实践

1. 技术债与代码扫描

“技术债”用来表述遗留技术问题对当前或未来开发的影响，自提出这一概念以来，它一直是软件开发关注的焦点之一。如今各大企业为了建立持续交付的能力，快速响应市场的变化，纷纷开始提升研发效能，技术债更是不可忽视的关键因素。

技术债一旦产生，都会对软件系统产生或大或小的影响。技术债涉及到的具体内容也非常广泛，一切不合理的设计或妥协都可以称之为技术债，比如：

• 因认知不足或成本原因而产生的不良架构设计或代码设计。
• 因能力或认知不足而选择非最优的技术框架或选型。
• 因成本或进度原因而没有完成的测试代码。

这些技术债短期都不会表现出明显的问题，但在项目长期迭代过程中，随着技术债不断的增加，软件系统的可维护性会直线下降，随之而来的是质量的下滑，这给后续的产品开发带来了非常大的问题。

以下是技术债务的一些偿还策略：

• 优先级排序：将技术债按照其对系统稳定性、可维护性和可扩展性的影响程度进行排序。优先处理对系统影响最大的技术债，以最大程度地减少未来的风险。
• 分配资源：为偿还技术债分配适当的资源，包括时间、人力和财力。确保团队有足够的资源来解决技术债问题，避免将其推迟或忽视。
• 重构代码：对存在技术债的代码进行重构，改进其结构和可读性。重构可以提高代码的可维护性和可扩展性，减少未来的技术债。
• 培训和知识分享：提供培训和知识分享机会，使团队成员了解技术债的影响和解决方法。通过共享经验和知识，可以更好地解决技术债问题。
• 持续监控和改进：建立监控系统，及时发现技术债的存在和影响。持续改进开发流程和工具，减少技术债的产生和累积。

总之，偿还技术债需要有系统性的策略和计划。通过优先级排序、资源分配、重构代码、培训和知识分享以及持续监控和改进，可以有效地减少技术债的风险和影响。

关于技术债的识别，这里提一下代码扫描工具。它通过扫描源代码以寻找代码中潜在的的技术债务。这类工具使用定量数据来帮助开发人员识别代码库中可能存在技术债务的热点，例如不规范的代码、不良的注释、过高的圈复杂度、存在安全风险的代码等。利用代码扫描工具，可以方便快捷的识别大部分债务问题，同时与DevOps工具平台结合，可以建立质量门禁，对于不满足质量设定要求的代码，通过门禁自动拦截。

这类工具的局限性之一是它们无法帮助您识别跨越代码库多个部分的大中型债务。他们也难以真正确定债务处理优先次序和解决问题所必需的背景信息。尽管有以上局限，但其相对低成本的投入和巨大的收益，是目前极为划算的首选实践之一。

2. 自动化测试

自动化测试是借助于测试工具、测试规范，从而局部或全部代替人工进行测试及提高测试效率的过程。相对于手工测试而言，其主要进步在于自动测试工具的引入。

测试活动的自动化在许多情况下可以获得最大的实用价值，尤其在自动测试的测试用例开发和组装阶段，测试脚本被重复调用，可重用脚本可运行很多次。这样一来，在功能不变的情况下，开发人员实现一次测试用例及脚本，就可以对自己新增或修改的功能代码进行多次快速验证。因此，采用自动测试可以获得很高的回报。

在进行自动化测试的实践过程中，我们需要注意以下几点：

• 在自动化测试之前设计测试：在开始自动化测试之前创建测试用例和场景。
• 从自动化测试中消除不确定性：自动化测试的一个关键点是能够给出一致的结果，这样当测试失败时，我们就可以确定是否真的出错了。
• 保持自动化测试的有效性：需求或设计的变更同样会对测试用例和脚本产生影响，要注意保持检查自动化测试的有效性和完整性。确保测试是最新的。
• 寻求快速反馈：快速反馈是自动化测试的目标之一，因为开发人员很想知道他们开发的东西是否可行，是否没有破坏当前的功能。为了获得这个快速的反馈循环，通常测试需要在组件或 API 层自动化，而很少要依赖 UI。
• 要注意测试成本：并非所有的测试都适合自动化。有些测试的性质非常复杂，需要许多下游系统检查，并且可能不一致，想要实现这类自动化，要付出很高的实现成本。在这些情况下，最好将这些检查留给手动测试。

进行测试自动化有以下几点显著收益：

• 沉淀知识，就是把知识沉淀到了自动化的脚本里面，而不是存在于某个人的脑子里。而对于掌握知识的这个人来说，他也减少了被打断的可能。
• 提高效率，解放生产力，这一点其实是一个很明显的好处，原来手工要花五个小时的事情，自动化可能几分钟就跑完了。
• 固化流程，降低出错率。也就是将我们的这个流程固化下来了，原本一件事情今天是A做，明天是B做，他们在做的时候可能就基于自己的理解来做，中间就会引入一些错误。而自动化就可以规避这种问题。
• 测试过程和结果可追溯，便于后续缺陷分析等。

  3. 引入测试代码覆盖率

前面说到测试左移是质量内建的主要核心之一。其中开发自测又是最容易落地，且见效最快的一项。开发自测，实际上是偏向于白盒测试，而测试代码覆盖率是一种有效的白盒测试技术，是衡量软件测试工作充分性和完整性的重要指标之一。 　
　
简单来说，测试代码覆盖率就是测试过程中已经被执行过的代码占准备测试总代码量的比例和程度，它关注的是在执行用例时，有哪些代码被执行到了，有哪些代码没有被执行到。

一个比较完整的代码覆盖率平台，应该支持以下功能：

• 既支持全量测试代码覆盖率，也支持增量测试代码覆盖率统计；
• 对源代码无侵入，无需对开发代码做任何改造，即可收集覆盖率数据；
• 覆盖率报告可视化，能定位到类、方法及代码行；
• 能识别定位团队开发人员的个人覆盖率情况，以便团队内部管理自测质量（扩展）；
• 能识别应用之间、团队之间、部门之间的测试覆盖率情况，以便组织层面管理测试质量（扩展）；
• 能进行以需求为单位的测试覆盖率情况，以便对应需求交付质量进行管理（扩展）；
• 能支持不同功能类型项目的编译，例如Maven、Gradle、Ant等（扩展）。

以上功能的前三项，一些开源/商业工具有一定程度的支持，几项管理要求的扩展功能在市场上目前很少有相关方面的支持，这一点需要各企业自行开发扩展。上海惠艾信息科技有限公司在这一方面经过一定时间的摸索和部分客户的落地实践，进行相关功能的持续改进和功能优化，目前已形成相对成熟“Hi-CC测试代码覆盖率平台”。

4. 其它补充实践

• 测试驱动开发（TDD）：TDD的目标是通过测试用例的驱动来指导代码的开发，并确保代码的正确性和可靠性。通过频繁地编写和运行测试用例，开发人员可以及早地发现和解决问题，提高代码质量，并减少错误。此外，TDD还可以促进团队合作和沟通，以及提高代码的可维护性和可扩展性。
• 结对编程：一种软件开发方法，其中两个开发人员共同工作在同一计算机上，共同完成一个任务。在结对编程中，一位开发人员充当"驾驶员"，负责实际编写代码，而另一位开发人员充当"观察者"，负责及时发现和纠正错误、提出改进意见等。它可以促进知识共享、有利于错误检测、提高设计和质量、加深交流与合作、促进知识传承。
  尽管结对编程可能增加了开发人员之间的沟通和协调成本，但它可以提高代码质量、减少错误、促进团队合作和知识共享，从而带来长期的收益。
• 代码评审：一种常见的软件开发实践，它是通过对代码进行系统性的检查和审查来发现潜在问题、提出改进意见和确保代码质量的过程。代码评审是一个持续不断的过程，应该在整个开发周期中进行，以确保代码的质量和可靠性。它需要团队成员之间的合作和沟通，以及对代码质量的共同关注。
• 缺陷管理：质量内建的的目标预防缺陷，尽量不产生缺陷，而不是关注缺陷的数量。缺陷管理在质量内建中起着重要的作用。它通过发现、记录、追踪和解决缺陷，从而形成缺陷分类和类型问题解决方案的沉淀。预防缺陷比后期修复缺陷更加高效和经济，因为它可以避免缺陷对用户和项目进度的影响。因此，缺陷管理在质量内建中的预防作用非常重要。

  五、质量内建实施本身的衡量标准

对于一件事情的实施质量，应该有一个共同认可的衡量标准，同样的，质量内建活动本身，也有做的好与不好，这个该如何去判断呢？

这里讲一下评判质量内建实施行为本身的度量准则。从根本上来说，质量内建的目的就是在生产的各个环节能够快速反馈及修正问题，从而使得整个生产过程流畅无阻碍，这也是保证既有完成功能可随时发布的重要前提。所以质量内建做得好的，一定是可以快速反馈质量的。因此如何衡量质量内建的实施状况，主要从快速反馈的四个方面来衡量：

• 质验快速性：大量验证，时间越短越好。衡量指标为用例执行平均时间。
• 质验准确性：验证结果准确可信，断言完成充分。衡量指标为用例执行通过率。
• 修复及时性：快速修复及时纠偏，持续改进。衡量指标为问题修复平均时长。

  六、质量内建的6个层次

质量内建在企业内部实施，有以下六个目标层次，而这些层次的推进也是质量验证逐步左移的一个过程，大家可以对照一下，看看自己或团队当前属于哪一层次：

第一层次：投产后验证，防止缺陷逃逸至外部市场。
第二层次：UAT测试和投产演练验证，防止缺陷逃逸出研发部门。
第三层次：SIT测试验证，防止缺陷逃逸出测试环境。
第四层次：DEV持续集成验证，防止缺陷逃逸出开发环境。
第五层次：开发本地验证，防止缺陷逃逸出个人开发环境。
第六层次：更好的需求、设计和开发实践，各环节不产生缺陷。

通过以上层次的层层推进，覆盖开发各个环节的相关人员，最终让质量内建的理念根植于每个团队成员心中，不容忍、不产生、不流转一个缺陷，所有人都把问题扼杀在自己的环节内，减少外部检查。质量未知或质量差就停止流动，直到质量变好为止。

原文地址：https://blog.csdn.net/weixin_68153586/article/details/134552958?spm=1001.2014.3001.5502