大咖简介

张晓霞(小瑕)，数金技术资深测试开发专家，负责数金（财富、消金、保险、网商）质量与技术风险团队。在互联网金融业务领域具备成熟的质量风险体系建设经验，在质量技术创新和团队能力升级方向也有丰富实践。作为TICA2022大数据&智能化的出品人，小瑕老师选题眼光毒辣，兼顾理论与实践，带来自动驾驶、AI自动化、大数据等各领域的6个topic，欢迎大家参与讨论。（购票方式见文章末尾）

前言：

质量保障体系已是近年广泛流行的提法，每个业务/产品，都需要有一套完整高效的质量保障体系。那么质量保障体系是由什么组成的？质量保障体系是如何发挥作用的？如何评价某个业务的现行质量保障体系？如何紧贴业务发展做质量保障体系的建设和升级？本文结合我做过的和看过的不同业务实践给出分析总结，供大家参考。

为什么强调紧贴业务四个字？

在行业质量保障体系持续发展之下，阿里蚂蚁作为质量行业实践领先者，通用质量保障体系在近几年已经日趋成熟，任何一个新业务/产品启动后，我们都能快速建设一套实用的质量保障体系，从流程到方案到工具平台支撑，基本半年到一年内就可以完成体系搭建，在业务上拿到80分水位以上的质量结果。当然，这显然不能满足大业务的质量要求，也不能满足质量人精益求精的追求。质量保障体系需要跟随业务共同发展，紧贴业务强调的就是贴合业务特性，紧跟业务发展节奏，持续在业务的不同阶段提供质量保障。

一、什么叫质量保障体系？

质量保障体系，在阿里蚂蚁语境下，通常是指贯穿研发流程进行的一系列质量活动，通过方案选型、策略决策、工具支撑、组织协同分工等，把质量活动进行系统化、标准化、流程化，嵌入在研发流程中做执行。质量保障体系是为了保障业务质量（拿到质量结果）。反过来也可以说，把一切保障质量的工作放在一起，就构成了质量保障体系。

注1：质量保障体系的执行人不限定于质量团队成员，也可能包括研发，pd，业务等多角色，本文重点讲工作内容，不强调角色分工。

注2：质量保障体系除覆盖研发流程外，可以进一步外扩覆盖业务流程，阿里蚂蚁也有一些团队有此类扩展实践，本文考虑实际情况，重点讲研发流程的质量保障，少许内容涉及业务流程的质量保障，下文不再过多说明。

典型质量保障体系示例图：

如图所示，我的定义是：质量保障体系=质量活动+工具平台+质量流程。

建设质量保障体系是为了达成质量目标，所有业务的质量目标都可以用同一句话形容：线上不出问题。这里对问题的定义，本质就是对质量标准的定义。

二、紧贴业务制定精细化质量标准：

传统软件的质量标准的定义包括功能性，可靠性，易用性，效率，维护性与可移植性六个特性（根据GB/T16260.1），以此为参考，互联网服务的质量标准一般强调功能性，稳定性，性能/稳定性，用户体验。

对一个业务来说，质量标准最具象化的表现就是Goc故障等级定义。Goc故障等级定义会从业务的各个使用场景拆解定义故障，通过故障的表现形式、时间空间程度（时长、影响范围）定义问题严重程度，对应到不同故障级别。

如改编示例所示：

当然，故障已是严重问题，是冰山露出水面的部分。除故障外，好的质量保障体系也应尽量减少冰山潜于水下的部分，即未到达故障级别的所有线上问题。每个业务内都应有线上问题的细化定义，来跟踪评价线上质量水位，回溯分析改进。

当业务发生变化时：如增加了一个业务场景，需要在故障等级定义里同步新增该业务场景，如业务场景体量（流量/用户数/社会影响力）发生变化时，要同步更新，同样，业务场景下线后，要删除对应故障定义。

小结：质量标准天然要紧贴业务精细化定义。

以对业务的影响方式、程度综合定义，并跟随业务发展进行及时同步刷新。要通过完整细致的质量标准，来牵引全面高效的质量保障体系。

 

三、质量活动、工具平台、质量流程的定义

3.1  质量活动：

经典的质量活动在各公司各业务都大同小异，一般可分为如下几个环节：评审（prd评审、系分评审），测试计划/用例设计，测试执行，测试报告，上线和线上测试。其中测试执行阶段可以进一步按研发流程细分为：CodeReview，单元测试，接口测试，集成测试，系统测试。

还可以基于上述质量活动进一步细分：如集成测试可以细分为内部联调、外部联调，或细分为正常功能测试和异常测试，系统测试可以细分为功能测试和非功能测试，功能测试可以继续细分为全链路功能测试、兼容性测试、用户验收测试、线上巡检等，非功能测试可以继续细分为性能测试、安全测试等。

随着软件到互联网服务的发展变化，质量活动的目的和形态都在持续变化，只要是对质量能够起到保障作用的工作事项，都可以认为是一项质量活动。如PD验收、灰度发布、白名单用户测试都可以归为质量活动。

3.2  质量工具平台：

好的质量保障体系一定要追求质量活动的工程化（工具化、平台化），因为质量工具能解决如下几类问题：

1.纯手工做不了的，由工具辅助完成：如查询db脚本，就是一类最简单的工具。

2.由工具平台保证不同人执行效果的一致性：如一个case执行后，有经验的人会校验若干个校验点（接口返回，日志，数据库，消息等各项结果的交叉验证），经验不足的人可能会遗漏某个校验点，这时候写成一键校验工具就可以保证每次执行的一致性，可以将团队所有qa的执行能力一次性提升到最资深qa的水平。

3.大幅提高执行效率：手工执行一个case，和工具平台并发n个case的效率差异，从几倍到上万倍都是可能的。

注：工具和平台的区别：工具通常指功能比较单一，开发成本较低，交互较简单的用于辅助测试的小功能应用，平台通常指功能更全，交互更体系化，能完成较复杂质量活动的复杂工程。平台也经常体现为若干工具的聚合体。

为什么质量工具平台非常重要？

前文《关于测试这件事》也提到过，测试工作天然有重复性（版本间的重复是回归测试，case间的重复是环境、数据、执行、验证），重复的价值是为了保障每个时间节点的程序质量，但重复性的成本如果都由人来承担，会随着时间、版本积累变得非常巨大，一定要通过工具平台的开发降低重复性成本。

3.3  质量流程：

前文提到，质量活动是伴随贯穿研发流程的，质量活动之间的串联组合就是质量流程。质量流程结合研发流程定义了每个质量活动的时间节点，准入准出，执行标准，以此保证每个质量活动的效果，进而保证整个项目质量结果。

质量流程还定义了质量活动的角色分工，开发、测试、pd、业务方都可能是某个质量活动的负责人。

质量流程也有自己的工具平台支撑，同样是为了保障流程的执行效果，执行效率，以及流程留痕用于回溯分析。（这里仍然适用重复性原则：项目间甚至业务间的流程执行存在很高重复性，流程平台的累积提效会很明显，所以基本上各公司都会有自己的流程工具平台。）

四、如何紧贴业务建设质量保障体系？

继续按照质量保障体系三要素：质量活动、工具平台、质量流程分别阐述。

4.1  结合业务特点做质量活动的定制。

质量活动有两个定制原则：

原则一：针对业务/产品的特有问题设计质量活动。《关于》一文中也提到了产品形态决定测试工作，简单来说，你需要对业务构建一个问题地图，然后设计对应的质量活动去发现这些问题。

举几个例子：

Case1：视频类业务会出现卡顿黑屏加载慢的问题，那么质量活动需要包含此类检测。

Case2：金融类业务会出现资金安全的问题，那么质量活动要针对资金安全做专项防控。

Case3：生态类业务会有第三方质量问题，那么要设计对应的质量活动把控第三方质量。

原则二：针对业务/产品的研发过程设计质量活动的部署点。大部分业务的研发过程都有通用的几个环节：系分，开发，联调，发布，所以大部分业务也都有对应的质量活动系分评审，单元测试，联调测试，预发验证等，本质是因为有这样的研发过程环节，才会在这些环节引入一类质量问题，那么按照“最早发现成本越低”的原则，最好是在引入问题的环节后部署质量活动精准发现这个环节引入的问题。

举几个例子：

Case1: 业务有很复杂的业务人员配置流程，这个环节会引入业务配置问题，可以在这个环节后定制质量活动，如配置规则校验，配置预跑等。  

Case2: 业务在运行时仍有新机构/新商户接入环节，可以定制质量活动，如新接入时进行联调验证、性能压测。

Case3: 业务有间隔性的数据跑批环节，那么在每次数据跑批结束后，可以定制质量活动，在每次跑批后做结果验证。典型业务有日切，月账单生成，关键报表生成等。

可以看到以上两个原则分别对应了空间-问题类型，时间-引入环节两个角度，每个质量活动的定制是为了拦截一种问题，而质量保障体系，要为了拦截所有问题，做到时空全面覆盖。

紧贴业务的质量保障体系，需要分析出业务的所有可能问题（包括共性问题和特性问题），然后通过一系列的质量活动去对应保障。如同人体分为呼吸、消化、神经系统等若干系统，系统再分为若干器官一样，质量保障体系通常分为若干防线，每个防线再分为若干质量活动。防线负责时间覆盖，目的是在适宜的流程节点做质量保障，防线内的质量活动负责空间覆盖，保障此时此刻的所有问题能够被拦截。

因为种种原因（人员执行，系统能力，时间周期等），单一质量活动和质量活动集合（防线），都很难做到对目标问题的100%拦截，这时多道防线之间的协同就可以再次增强拦截效果：在前一道防线遗漏的问题，后一道防线需要有再次拦截的能力。防线间的重叠虽然会有一些成本增加，但拦截效果自然也会更好。

小结：质量活动如何紧贴业务？

1.分析业务的所有问题类型和所有引入环节。

2.按问题引入环节设计多道防线，做到引入环节的第一时间覆盖。

3.在每个防线设计若干质量活动。做到防线内问题的分布空间覆盖。

注：有同学可能会问，我刚开始负责某类业务，我怎样知道他会有哪类业务特性问题，或哪类业务特性环节，来定制质量活动呢？建议：拉取本业务一段时间的所有线上问题（如一年）、或其他同类业务线上问题中回溯分析，如果历史记录不全，可以主动向资深业务、技术同学咨询。

4.2  结合业务特性识别重复性工作，建设质量工具/平台。

重复性原则在新建和发展质量保障体系时都需要考虑。

在新建质量保障体系时，默认需要建设一套基础质量平台（如流程平台，bug管理平台，自动化框架等），要尽量选型市面或公司内较成熟的质量工具平台，减少新开发成本。

然后结合业务特点识别仍存在的较高重复性工作，建设符合业务特性的质量工具/平台，如测试数据构造工具，页面检测工具，结果对比工具等。

在业务增长发展过程中，随着团队规模增加，需求并发增加，业务体量增加，特定质量活动的重复性会进一步增加，要保持敏锐观察，识别重复性的变化趋势，在恰当的时候引入或建设质量工具/平台。

如机构生态类业务，已知业务要扩展到多机构，机构联调这项质量工作的重复性会增加，可以提前建设机构联调平台。

如营销类业务，如果只是一年一次的活动类型，工具化成本收益不一定明显，如果业务决定将某类活动转为常态化营销，如一个月一次，那么把活动页面验证、数据验证、压测数据&脚本等工作做成工具化就可以大幅提升效能。

还有一类重复性容易被忽视：不同质量活动之间的动作重复性。如账号构造工作，在联调测试、回归测试、ui测试中会被重复用到，这时也适合将其工具化账号构造，可以通过账号自动生成、账号池管理等工具平台进行提效。再比如在长链路复杂业务中，不同质量活动的排查分析动作也会有重复性，可以做快排分析工具。

工作中经常有同学问我，想做些工具平台开发，但不知道做什么好，那么最简单的方法就是，分析自己的工作内容和时长，聚类出最消耗你时间的工作内容，用工具平台提效。把工作内容拆的越细，越容易聚类出某一个原子工作。比如某中台同学要处理前台业务咨询比较多，就可以做个钉钉机器人自动回复一些常见问题。再比如，业务质量owner经常需要回溯分析线上问题，也可以顺手写个脚本做个自动报表。

小结：质量工具平台如何紧贴业务？

1.结合业务特点识别重复性较高的质量活动，选型或建设质量工具平台。

2.结合业务发展趋势选择重复性持续增加的质量活动，或更细的原子动作，在恰当时间沉淀能力，建设质量工具平台。

4.3  紧贴业务研发模式制定质量流程。

通用研发流程和质量流程大家都很熟悉了，那么业务特性对质量流程会带来什么样的新要求呢？

从质量要求来看，高质量要求的业务，质量流程环节多，准入准出要求高。

从测试周期来看，迭代节奏快的业务，质量流程注重灵活，可根据具体项目做流程简化。

从协同角色来看，业务流程复杂，职能角色多且分工细致的业务，质量流程要结合角色权责制定流程流转、审批等细节，并在系统中留痕。

从业务发展状态看，成熟业务的质量流程相对稳定且在线化程度较高，发展期业务的质量流程需要定期刷新调整，以适配业务发展节奏。

研发模式对质量流程的影响显而易见，大项目整体发布、小迭代班车发布、业务域独立发布，前中台联合发布等不同研发模式下，质量流程也要有相应适配，最重要的是找到质量流程和研发流程的耦合点，以质量标准作为研发流程的准入准出要求。考虑到研发流程（从项目需求到发布上线）的所有环节是在不同的角色之间做流转，每个环节的主导角色不同，质量流程也应该贴合该环节的主导角色，质量保障方式，工具平台能力，明确质量流程的交付物标准。如开发提测环节以单测覆盖率为交付标准，测试以测试报告为交付物，pd验收以截图为交付物。

整体来说，质量流程要兼顾质量要求和效能支撑两方面，要通过质量流程的约束达成质量结果，也要避免质量流程过重影响研发效率。

小结：质量流程如何紧贴业务？

1.分析业务质量要求，业务发展阶段特点、业务角色职责分工。确定质量流程在严谨和灵活之间的平衡。

2.分析研发模式特点，确定质量流程和研发流程的耦合点，定义质量环节，制定交付标准。

3.跟随业务发展定期review质量流程适用性，及时刷新调整。

 

五、有了质量保障体系还要有质量策略：

我在从事质量工作三四年后才开始接触质量策略这个概念，最开始的时候还有一点理解困难：既然我已经有全面的质量方案（那时候还没有质量保障体系这个概念），也一直能够做项目做的很好，质量策略又是用来解决什么问题的呢？

这个概念可能在各团队的解读不尽相同，我仅说明我对质量策略的理解：在业务质量保障体系中，在质量、效率、成本三者中取平衡，作取舍，在具体项目中，定义质量防线、质量活动的策略性标准。基于此，要持续跟踪线上业务质量表现，定期回溯分析质量策略执行情况，做质量策略调整。

简单来说，当建设了比较完备有效的质量保障体系后，在落地应用时，结合现实情况做更具体的执行标准，就是质量策略。质量策略要有自身逻辑（质量、效率、成本策略），并在调整过程中保持逻辑一致性。

比如，质量保障体系规定了要做灰度发布，那么怎样做灰度发布？质量策略可以进一步规定执行细节：至少要包含从1%->10%->50%->100%四个阶梯的灰度，且灰度时长不小于2小时。

再比如，质量保障体系约定了低风险项目可开发自测，那么质量策略可以进一步定义低风险项目包括bug fix，页面展示修改类项目等。

再比如，质量保障体系要求回归测试要完整，那么质量策略可以进一步定义完整回归的具体要求：全部P0P1用例(不区分手工自动化) or 全部自动化用例 or 人工评估的所有场景用例 or 代码变更分析的所有自动化用例 等。

可以看到，质量策略比质量保障体系要更具体，并且可以对项目分类细分定义。质量策略的逻辑并不是拍脑袋，而是对业务进行测算后进行的科学性制定：

如灰度的阶梯和时长，需要结合业务流量，业务故障表现，业务流转周期、业务监控应急能力等做综合分析。

再比如低风险项目也要分析一定周期内项目类型分布，项目风险表现，团队自测能力等。

再比如回归策略需要分析线上问题表现，回归能力/周期，其他后置防线能力等进行质量、效率、成本（时间、机器）的综合测算。

从上述分析可以看到，质量策略天然就是贴近业务而制定的。如果没有业务语境，很难定义质量策略。紧贴业务，也就是根据业务中的实际情况（最好是数字化的统计分析），评估质量、效率、成本现行情况，决策三者的平衡策略，最终制定项目内的质量策略要求。

质量策略在中大型质量团队中尤其重要，当一个重要业务域可能由多个人或多个团队承担质量工作时，需要通过质量策略约定不同人在同类项目的执行一致性。小型质量团队中，通常一个系统由固定的一位同学主负责，这时这位同学相当于非显性的自定义了这个系统的质量策略。（这大概也是我最初理解困难的原因）

小结：质量策略是质量保障体系的细化深化。

1.质量策略是具体项目的执行标准。通过对不同类型项目的质量、效率、成本做测算分析，制定平衡取舍策略。

2.随着业务发展、质量能力提升，质量策略需要保持刷新。

3.中大型团队需要对质量策略达成共识，来保证同类项目的执行一致性。

 

六、质量工具平台是如何支撑质量保障体系的：

虽然前文定义了质量保障体系=质量活动+质量工具平台+质量流程，但质量工具平台在最开始并不是质量保障体系的必需环节。比如很多互联网产品在初创期的质量工作以手工为主，完全没有质量工具平台的支撑也可以完成质量工作。那么质量工具平台对于质量保障体系的支撑价值是怎样体现出来的呢？

我通常把质量工具平台分为两类价值定位：面向质量or面向效率。

当为了完成某个质量活动，靠纯手工无法完成，必须通过质量工具平台的辅助时，这类工具平台的定位就是面向质量型。如性能测试这个质量活动无法通过纯手工完成，性能测试工具就是面向质量的工具平台。如果一个活动可以靠手工完成，工具平台能够相比手工执行大幅提高执行效率，这类工具平台就是面向效率的。如UI功能测试可以通过手工进行，也可以通过UI自动化脚本进行。这时的UI自动化脚本就是面向效率的。

实际上，很多质量工具平台由于提升了非常高的执行效率，以至于同样项目周期内，手工执行效率和工具平台支撑效率完全不可比。比如线上流量采集回放，在平台支撑下能够做到万级别case的小时级执行，而要人来执行万级别的case，在任何项目周期中都是不可能的。这种我也会把它从提升覆盖效果角度划归到面向质量类。

那为什么要区分这两类定位呢？因为面向质量和面向效率的价值衡量标准是不一样的：

面向质量的工具平台，要衡量质量问题的解决程度，可以结合上文定义的质量活动、质量防线，先确定质量工具平台是在支撑哪个活动/防线，再衡量对活动/防线的支撑覆盖率，是解决全部问题还是其中某一类问题，最后衡量最重要的质量解决效果（覆盖率，发现率，召回率，准确率等）。

面向效率的工具平台，要找到效率对比对象：人工或某个使用中的工具平台，在完成质量效果大致相当的前提下，才能相互对比：人工执行效率，已有工具平台执行效率，新工具平台执行效率。在效率对比有优势情况下，还要加上一次性成本和维护性成本的考量：接入成本、迁移成本、培训成本、每次使用成本、维护升级成本等。

可以看到，因为我们的质量保障体系的目标是优先质量，兼顾提效，如果一个工具平台是面向质量的，只要开发和使用成本可接受，就可以直接决策使用。如果一个工具平台是面向效率的，那么需要更精细化测算提效价值和成本，做性价比综合决策。

当然，实际工作中要先结合业务诉求做质量、效率、成本的整体策略，再进行具体工具平台决策，能够更聚焦做到价值最大化。

通常质量保障体系在初建时重点解决质量问题，保障业务不出质量问题，稳定发展，当业务进入质量稳定期，质量保障体系要转向追求效能成本，支持业务快速发展。当业务继续增长时，很可能碰到新的质量问题，质量保障体系也要及时升级，做到质量、效率动态平衡。

以上都是质量工具平台对质量保障体系的价值支撑，如果把质量作为一个业务，那这些都属于业务价值。除此以外，质量工具平台也有本身的技术价值。质量工具平台自身技术的先进性、创新性、复用性、技术影响力等，也可以作为单独的价值衡量维度。工具平台的技术价值评价也是个很大的话题，本文不做过多展开。

小结：质量工具平台从质量和效率两个角度对质量保障体系进行支撑。

对质量活动、防线的支撑覆盖度、力度越大，质量或效率效果越好，质量工具平台价值越大。基于质量效率价值再追求工具平台自身的技术价值。

 

七、质量工具平台选型和演进的几个原则：

质量工具平台除了是对质量保障体系的重要支撑，也是对质量人发展的重要支撑：如果说思路经验是能力的无形体现，那么工具平台则是技术的有形体现。当我们说沉淀技术能力时，通常就等于说：写点代码，开发点啥，让别人一起用。

原本试图总结我所接触的质量工具平台选型和演进过程，但真正敲起键盘时，发现这是个很大的话题，哪怕仅列举介绍阿里蚂蚁体系内的质量工具平台，都能洋洋洒洒抄上好几大篇，而进一步的对比分析优劣评估，其实更适合站在具体使用方做具体分析。考虑到这个话题在ata上也有挺多好文分享，我就仅分享一下我做质量管理时的一些参考判断原则吧。

接着前文来说：重复性是质量工具平台之母。每个业务在初期、发展期、成熟期都会对质量工作的重复性带来影响，所以选型质量工具平台的最重要原则就是：要提效，要综合提效。能够把人工作的重复性转移到机器承担，借助机器执行边际成本低的特点，提高执行效率。要注意：质量工具平台通过转移重复工作减少人的成本时，很可能会隐含增加另一种工作成本。如自动化用例框架，能够大幅提高自动化执行效率，但和手工测试相比，增加了自动化用例编写成本。在业务变化节奏较快时，这部分成本很可能变得不可承受,类似在界面频繁改版时，UI自动化因成本过高而废弃/放弃的案例很常见。所以提效不是单一成本的换算，要对比before after的综合成本变化。

结合上文分析的质量活动、防线，一个质量工具平台最好能锁定某个稳定存在的质量活动、防线作为服务对象，以保证质量工具平台自身的存续性。

用户的使用能力、使用习惯也需要考虑。比如拖拽式编辑页面和步骤选取式编辑页面，团队接受度会有差异。而脚本编辑式操作界面，在提供给外包同学使用时，要考虑额外培训成本。

要尊重历史积累。很多质量工具平台是一个复合体。它包括了一些能力沉淀，以及使用者在使用过程中积累的测试资产。如case，规则，系统接入时的配置，该工具平台和其他工具平台的自建联动能力等。不同的质量团队有类似的质量工具平台是很常见的。可能因为之前没有成熟的通用工具平台可选，也可能因为最开始有个同学低成本顺手写了个工具就一直发展下来，不论何种原因，只要工具平台上已经沉淀了很多数据、规则、能力等，就需要慎重考虑它的后续发展，不应一刀切要求迁移到另一个官方推荐的成熟工具平台。

在管理上不要限制大家“造轮子”。不要重复造轮子是我们的共识，那为什么仍然有重复造轮子的行为和吐槽？因为实际工作中，极少有哪两个工具平台是完全重复的轮子（同一个轿车车型的轮胎还有不同型号呢），每个工具平台在建设和发展期都有自己特有的定位和规划。

那么如何避免重复造轮子呢？首先要做到工具平台信息的充分共享、及时刷新，避免因信息不足导致的重复造轮子，其次在有同类工具平台新建初期，及时发起评审，确定定位和发展路线，避免发展成已有轮子的复制品。最后，要在大横向组织里阶段性review同领域工具平台，做好顶层设计（定向发展or关停并转）。

自己生的娃要自己养大。如果是团队共同决策建设的工具平台一定要维护好。负责人变动了就及时换人补上。很多时候不是大家想重复造轮子，而是因之前的工具平台无人维护，同学不得已搬迁很多测试资产到自建的新平台，这种情况对人对团队都很消耗。

要保证工具平台体系的持续发展。质量工具平台是用于支撑质量活动、防线的。而质量活动、防线会随着业务发展日趋完善稳定，要结合质量活动、防线发展趋势建设工具平台。比如自动化是所有质量工具平台的起手式，要考虑好自动化工具平台所服务的具体防线是接口测试还是联调测试，接口测试注重高频稳定，联调测试注重快速反馈，贴合防线具体要求做迭代，就能保证发展持续性。反之如果试图同时服务好接口测试和联调测试，很可能两者都服务不好，进而出现新的工具平台。

单一工具平台不一定能跟随发展到最后，但每个稳定质量活动、防线需要有持续跟随的工具平台。最终质量工具平台会按照质量防线、体系的组织方式，形成质量工具平台体系，通过接口、服务、数据的串联，形成一致性的服务体系。

小结：

1.按提效原则建设或选型，锁定要服务的质量活动、防线

2.过程中综合考虑开发成本、使用成本、迁移成本

3.阶段性考虑质量工具平台的整合、共建、打通。

4.在稳定的质量工具平台之上，串联形成工具平台体系。

八、如何评价质量保障体系？

为过程鼓掌，为结果买单。

不论质量保障体系建设过程中如何全面论证高效执行精细覆盖，先看业务质量结果。是否有重大故障，是否有故障，跟其他同类业务对比故障结果怎样，跟去年同比环比故障/线上问题结果怎样，线上问题表现怎样，这些都是典型的质量结果衡量。

拿到质量结果后，再来看，是通过什么样的质量保障体系拿到的结果，是因为开发代码写得好，还是测试测的好？这时就要通过业务特性，问题特点，问题的时空分布，防线部署，质量策略，质量活动执行标准等一层层抽丝剥茧进行分析论证。

最后是看质量工具平台的支撑度。

如果在上述过程中，质量工具平台发挥的作用很小，那么说明大部分功劳来自于测试人员，而人员经验能力的推广培训成本非常高，过多基于人经验的质量保障体系可能是好的质量保障体系，但一定是不够稳定的质量保障体系，一是核心骨干成员流失肯定带来体系保障能力的大幅波动，二是即使人员稳定，在多次项目执行中，不同人的执行一致性，以及同一个人的多次执行稳定性，也不如系统工程的一致性。

如果质量工具平台起到了全面有效的支撑，那么再继续衡量工具平台的技术能力水平，作为技术价值评价补充。

小结：

1.先看质量结果

2.再看对业务质量问题的拆解分析和体系化的应对

3.最后分析质量工具平台的支撑度和技术价值。

注：以上虽是个人经验为主，但经过这几年在阿里蚂蚁做晋升评审，对各业务的评价适用性基本验证ok。

总结：

质量保障体系是个很大的话题，本文从质量活动+工具平台+质量流程三要素，以及质量策略取舍，质量工具平台发展过程、质量保障体系的评价进行了一些经验分享，希望对大家有所帮助。

彩蛋：如何评价一个优秀的大厨

1.做的饭菜要好吃。好吃的程度定义可能因人而异，是否好吃的评判大概率是一致的。

2.要有体系的方法论，能够紧贴食材特性，制定烹饪过程，从食材预处理、配菜选择，烹饪火候时间掌握，调料搭配，装盘摆盘等各环节，都能紧贴菜色要求，参考标准流程定义，做各个环节的专业处理，以及在食客有口味要求时做差异性策略。

3.看器具在过程中发挥了何种作用：是否有专业的器具支撑食材的储藏、洗涤、调制、烹调，看器具如何保证处理效果、效率和过程的稳定性。也可以顺带评价一下器具本身的指标能力、品牌影响力。

这样对比下来是不是挺类似的？这样就很好理解简单业务和复杂业务的挑战差异了。做一个西红柿炒鸡蛋和一桌满汉全席的挑战性对比，就类似我们测一个简单的小app和测一个复杂的亿级用户业务的挑战性对比。每个大厨最开始都做过西红柿炒鸡蛋，但大厨的做法和爱好者的做法必然有区别。我们也一样，从简单产品/业务开始就要注重紧贴业务、体系化思考，一步步建设能够支撑复杂业务的质量保障体系。