09 微服务架构下的质量保障体系全景概览

上一模块，我详细讲解了微服务架构下的分层测试策略，它可以确保系统的所有层次都被覆盖到，更多体现在测试活动本身的全面性和有效性方面。但要想将质量保障内化为企业的组织能力，就需要对质量保障进行体系化的建设。那么从今天开始，我将讲解微服务质量保障体系的相关内容，本课时主要介绍质量保障体系的全景概览。

质量保障体系：以不变应万变

不知道你有没有注意到一个现象：虽然不同的业务之间有非常多的差异性，但当它们在质量保障方面建设得比较完备和完善时，其质量保障体系框架大同小异。

为什么会出现这种情况呢？这需要回归到“质量保障”和“体系”的定义上来。

• 质量保障的定义

通常情况下，对业务发展来说，质量保障体系是企业内部系统的技术和管理手段，是有计划的、系统的企业活动，目的是满足业务发展需要，生产出满足质量目标的产品。

对应到微服务架构下，说得更接地气一点就是为了共同的目标，一群人在一块儿做事。总结如下：

所以，质量保障体系是通过一定的流程规范、测试技术和方法，借助于持续集成/持续交付等技术把质量保障活动有效组合，进而形成系统化、标准化和规范化的保障体系。同时，还需要相应的度量、运营手段以及组织能力的保障。

• 体系的定义

体系：泛指若干有关事物或某些意识按照一定的秩序和内部联系组合而成的整体，是不同系统组成的系统。

听起来比较抽象，以项目管理知识体系 PMBOK 做个类比，我们都知道管理一个项目是比较复杂的，如果没有类似的经历经验，或者相关的知识和技能，你甚至都不知道应该从哪里入手、应该关注哪些方面、每个方面应该怎样推进，等等。而 PMBOK 对项目管理所需的知识、技能和工具进行的概括性描述，即项目管理的五大过程组和十大知识领域，掌握了这些体系知识，你就具备了管理任何项目所需的知识基础。

PMBOK 是 Project Management Body Of Knowledge 的缩写， 指项目管理知识体系的意思，具体是美国项目管理协会（PMI）对项目管理所需的知识、技能和工具进行的概括性描述。它涵盖了五大过程组和十大知识领域，其中，五大过程组是启动过程、规划过程、执行过程、监控过程、收尾过程；十大知识领域是整合管理、范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、风险管理、采购管理、干系人管理。

可见，当一个体系进行了比较合理的抽象和概括后，它能够把一系列的活动拆解成不同的方面，这些方面又相互协同形成一个有机的整体，做到以不变应万变。我想，这也是质量保障体系对每个测试从业者个人职业发展来讲最有价值的地方，因此一定要尽早建立质量保障体系的意识，从全局视角理解所在业务中的质量保障体系。

建立质量保障体系的切入点

可能你会疑问，既然质量保障体系都大同小异，那我们照着它做不就可以了吗？其实不然。这里需要先对齐一下认知：

质量保障体系，不能为了建设而建设，一定要结合业务特点和所处阶段，它是为解决特定问题而逐渐形成的体系。

质量保障建设的终点都一样，但业务特点和阶段不同，各个环节建设的优先顺序大不相同。实际在进行质量保障建设时，通常会从业务特点和阶段、业务目标和质量挑战两个方面去切入。

业务特点和阶段

业务特点和阶段决定了业务最核心的关注点，也影响了质量保障工作的侧重点，举例来说：

• 搜索引擎类的业务，通常的特点是高并发、高存储量，且搜索内容对时效性要求较高，它属于效果类业务，线上会有各种类型的 badcase。那么，数据生产过程的质量把控、搜索效果的评测、服务可用性和并发性等尤其重要。

• 出行类业务，如用车场景等，通常的特点是业务元素多（乘客、司机、租车公司等）、业务链路长、需要线上线下协作，同时涉及金钱交易、责任归属、人身安全等，客诉问题多种多样。那么，全链路的自动化测试和性能测试、客诉响应机制等建设就比较关键。

• 金融类业务，对安全性要求极高，同时需要响应市场和政策要求。那么安全类测试、风险控制类的产品策略等方面的质量保障非常重要。

另外，在业务的不同阶段（初创期、探索期、成长期、稳定期），对产品迭代和质量的要求也有所不同，这些都需要综合考虑。

业务目标和质量挑战

不同的业务特点对应的业务目标也有所差异，但共性都是确保产品质量高、生产过程高效，从而实现业务价值，这体现出对质量、效率、价值三个维度的要求。伴随着微服务架构下带来的各种质量挑战，满足这三个业务目标将更具难度，因此在进行质量保障建设时，要尽可能地做到如下效果：

• 自动化。主要是为了提高研发过程（研发、测试、发布）的质量和效率，引入丰富的测试工具和技术，建立完整的持续集成和持续交付机制；

• 全流程参与。测试团队需要通过规范和工具建设等，贯穿业务价值全流程，把各团队高效组织起来共同完成业务目标；

• 泛质量管理。变被动的验证为主动的预防，变传统的代码质量管理为业务全流程的泛质量管理，在各团队中推进质量文化建设。

微服务架构质量保障体系的全景概览

基于上述分析，通用的微服务质量保障体系如下：

如下是质量保障体系的关键方面，后续课程也将按如下内容展开讲解。

• 项目管理和流程规范：每个业务所做的事情都是把战略规划拆解成大的业务目标，再进一步拆解成产品需求。产品需求又经历了产品研发、运营&运维、售后服务这样的业务价值全流程。没有规矩不成方圆，在这个过程中，无论项目管理还是流程规范，都是保障质量中非常关键的一环，只有建立起闭环、分工明确、易执行的流程规范，才能保证其可落地，从而形成业务价值过程的正循环。

• 微服务测试技术： 除功能性之外，质量还有其他很多属性，如可靠性、易用性、可维护性、可移植性等，而这些质量属性就需要通过各种专项测试技术来保障了。同时，还有许多测试技术的首要价值在于提升测试效率。因此合理地组合这些测试技术，形成测试技术矩阵，有利于最大化发挥它们的价值。

• 持续集成与持续交付：微服务的优势需要通过持续集成和持续交付的支持才能充分发挥出来，这就要求在执行测试活动时提高反馈效率、尽快发现问题。一方面要明确各种“类生产环境”在交付流程中的位置和用途差异点，保证它们的稳定可用。另一方面需要将各种测试技术和自动化技术集成起来，使代码提交后能够自动进行构建、部署和测试等操作，形成工具链，这样才能实现真正意义上的持续集成和持续交付。

• 度量与运营：管理学大师德鲁克曾经说过“你如果无法度量它，就无法管理它”。要想能有效管理和改进，就难以绕开度量这个话题。业务的目标是“确保产品质量高、生产过程高效，从而实现业务价值”，在质量保障体系中，我将基于质量、效率、价值等多维度视角建立起基础的度量体系，并结合定期运营做定向改进，形成 PDCA 正向循环，促使各项指标稳步提升。同时，需要特别警惕的是，度量是一把双刃剑，这里我也会告诉一些我的经验教训和踩过的坑，避免走错方向。

• 组织保障：打铁还需自身硬，质量保障是每个测试团队的天职，测试人员要努力打磨自身的质量意识和质量基本功，通过上述手段不断提升产品质量。需要注意的是，微服务架构下带来的质量挑战严峻，产品迭代飞快，离不开组织中每个参与部门的努力，而单靠测试人员已经无法保障好产品质量。正如质量大师戴明所说，质量是设计出来的，不是测试出来的。因此在组织中树立起“质量文化”至关重要。在这部分内容里，我将介绍常见的参与方的角色、职责和协作过程中的常见问题、对策，以及如何营造质量文化等内容。

总结

本节课我讲解了质量保障体系的内涵，它将质量保障内化为企业的组织能力，其基本框架可以以不变应万变。无论对业务还是对测试人员自身来说都至关重要。

紧接着我讲解了微服务架构下的质量保障体系的切入点，列举了搜索引擎、金融产品、用车场景等业务的常见特点，从业务特点和阶段、业务目标和质量挑战等方面切入，从而影响质量保障建设的侧重点和子方向的落地优先级。

最后我给出了质量保障体系全景概览图，它包括项目管理和流程规范、微服务测试技术、持续集成与持续交付、度量与运营、组织保障等几个重要组成部分，并介绍了各部分的内容，它们相互协同为质量保障体系添砖加瓦。

你所负责的项目或业务，是否是微服务架构？如果是，它的质量保障体系是怎样的，在这其中，你自己的掌握情况如何，请写在留言区。同时欢迎你能把这篇文章分享给你的同学、朋友和同事，大家一起来探讨。

相关链接：
https://winderresearch.com/how-to-test-in-a-microservices-architecture/
https://www.gocd.org/2018/05/08/continuous-delivery-microservices-test-strategy/
https://www.softwarecertifications.org/software-testing-body-of-knowledge/
https://developer.51cto.com/art/201911/606778.htm

---

精选评论

**莹：

我感觉公司在评估工作量的时候总是偏差很大。在听完需求后，就需要立刻预估工作量是否开发的工作量应当先出设计文档再定工作量呢？目前我们测试工作量是根据开发工作量来定的，开发的工作量有偏差，也压缩了测试的时间。若只凭用例来再预判测试时间，是否也有风险呢？

    讲师回复：

    估时是研发项目过程中的关键环节，它是研发人员和测试人员工作顺利开展的重要保证。估时出现偏差将直接影响研发测试过程的质量和效率，如果经常出现偏差或偏差很大，也容易陷入恶性循环。本问题的核心问题点是估时偏差很大，应如何改变？从表述中进一步拆解，包含了3个子问题：
1)听完需求后立刻评估工作量，因此估时应该在什么时间点进行？
2)测试人员的工作量是根据开发人员的工作量来定的，这是否合理呢？
3)如果凭测试用例预判测试时间，是否有风险？

1)无论是需求预沟通后估时还是需求评审后估时，都不能相对准确地进行预估，比较建议的时间点是在开发人员进行技术评审后进行估时。需求评审后只能知道从功能层面或端到端的视角，有哪些需要测试、哪些需要回归等，而技术方案则包含了技术实现思路和细节等内容，这有助于开发人员对工作进行估时，也使测试人员能快速理解方案目标与测试场景，设计合适的测试用例来规避风险。
2)测试人员的工作量是根据开发人员的工作量来定的，这并不合理。因为不同的需求目标和实现类型，对开发人员和测试人员的影响差异比较大。举例来说，重构类需求，对开发人员和测试人员来说，工作量都比较大；性能调优、类库升级或其它非功能性的需求，一般不影响业务逻辑功能的话，开发人员有一定的工作量，但测试人员的工作量比较小；涉及底层模块代码的改动，开发人员的工作量通常不大，但测试人员的回归工作量相对会大一些；因此，建议技术方案评审后，由开发人员和测试人员分别进行估时。两者的估时时长比例作为参考着，如果某方估时过高或过低，可以多方Review下估时逻辑是否合理。
3)如果能够在技术方案评审之后进行工时预估，则没有太大必要等到测试用例完成后再预判测试时间，显然这时侯才给出测试时间已经比较晚一些了，不利于项目的规划和后续工作的开展。
另外，估时出现偏差较大时，建议在项目告一段落后进行复盘，分析出来评估时的因素与实际影响工作量的因素的差异点有哪些，以便在后续评估工作量时把这些相关因素考虑进去。

**用户6034：

老师 可以讲下质量分怎么设计?

    讲师回复：

    没有太理解“质量分”的定义是什么，如果有可能建议把问题再明确下，我暂且按照字面意思把质量分理解为给软件项目的质量属性打分：
可以给软件项目的质量按流程先后进行分段，比如需求质量、开发质量、测试质量、交付质量等，并给它们分配一定的权重，比如需求质量20%，开发质量30%，测试质量20%，交付质量30%；再给各个阶段定义3-5个最重要的指标，给每个指标也分配一定的权重，这样就可以按项目、时间周期、团队等维度打出具体的质量分数来，有了这个分数，更方便做横向和纵向比较，有助于定向改进。
如果我的理解是正确的话，可以按此逻辑把框架先搭建起来，具体分哪些阶段、有哪些指标，是通用的，也是可以逐渐磨合和演进的。