最近部门在推质量标准化，通过质量标准化，推动质量内建，从而提高研发部门的交付质量，我也深度参与其中，并在推进过程中总结了一些经验以及思考，在此通过以下定义、共识、实践三个大方向和大家分享一下。

一  定义

1  质量标准化

何为质量标准化？用个不太恰当的比喻，大家都知道工厂的流水线作业，每个位置上的人或者机器要做什么都是提前规范好、定义好的，流水线上的商品从原材料到成品经过的都是同一套流程，因此成品间的质量不会相差太远。研发流程和流水线作业有一定的相似性。我们希望通过标准化各条业务线的研发流程，以做的比较好的业务线作为标准样板间，规范出一套标准化的流程，并适用到其它业务线，从而使各条业务线都能进行高质量的交付。

2  质量内建

不少研发团队的同学都认为质量都是靠测试同学去守护的，会认为产品出现了质量问题，是测试的锅，这是对测试工作和质量保障的一种狭隘的认识。测试同学是质量的守护神，可是质量不能只靠测试同学在最后一环去兜底。想要给用户交付高质量的产品和体验，必须是在研发流程各个环节都遵守质量规范，在需求评审、方案设计、开发、自测环节上的产品、开发、测试同学都要有质量意识并严格执行质量规范，这就是质量内建。

3  交付质量

交付质量包含系统质量和产品体验两部分。系统质量指的是系统的功能完备性、系统的稳定性和健壮性，产品体验是指客户使用此产品时是否有丝滑的体验。

二  共识

要让研发流程中的各个角色都愿意去践行一套统一的标准和规范，必不可少的条件是各个角色意识形态上的统一。只有团队的思想一致了，标准和规范才能被推进并落实。在推动 ICBU 跨境资金-国际结算团队标准化建设的过程中，我们团队从上到下首先在以下观点下达成了高度统一。

1  质量不只是测出来的

在知乎上看到针对“质量是被设计出来的，还是被测出来的”问题有一个讨论，觉得写的挺好的，从不同角度分析了这个命题，我把它摘抄出来，针对“质量之道”的本源之争，大家的发言很踊跃，我摘抄了几个具有代表性的：

A同学：我认为质量是设计出来的，在设计上考虑的各种非功能质量数据，都会落地到代码中。设计的优化会不断的驱动系统质量的优化。

B同学：我认为质量是测试出来的，设计的东西可以避免已知的问题，但在实际测试的过程中，还是会发现其他未考虑到的问题，例如兼容性问题，你能提前通过设计预防吗？所以测试发现问题，问题驱动质量提升。

C同学：听完B同学的发言，我更坚信了质量是设计出来的。在不断的BUG驱动下，我们打补丁式做出来的系统，质量会更好吗？打补丁解一时之急，而后续系统性的设计、重构、升级，才是提升质量的关键点。所以...

D同学：如果站到产品层面，我们会怎样去定义产品好不好？在我们定义产品好坏的质量模型里，很可能会包含软件研发相关的非功能质量属性(ISO9126)，可能会包括产品舆情、竞品对比中挖掘出的东西。例如，我们去定义一款内容推荐产品的好坏，除了“内容不重复”、“多样性”等维度外，“是否支持分享”、“是否支持点赞”也会成为质量好坏的评判标准，新功能上线、满足需求，用户就会认为产品好。我们的认知会不断升级，“好”的标准也会有更高的要求。用户无时无刻不在使用、测试、反馈，让质量不断变好。

2  既要、又要、还要、且要

上述的四位同学的观点，代表了不同的质量理念和追求：

1. 谋而后动的观点：无论是对需求的二义性分析、对设计中UML图的流程分析、时序分析、状态分析，都是希望能够磨刀不误砍柴工、降低成本。A同学说得对。
   
2. 探索式测试的观点：无论是保证在设计变成代码的过程中是否100%的完成翻译，还是在测试的过程中受到启发认为应该写下更多的逻辑代码，都是希望所见即所得，想人之未想。B同学说得也对。
   
3. 技术债的观点：无论是对前段时间的补丁代码进行重构，还是对系统进行架构的升级，还是对基建能力进行优化，都是希望能够打好底盘，走的更远，走得更稳。C同学靠谱。
   
4. 持续改进的观点：无论是做竞品分析、舆情分析、线上主动检测、监控、产品质量模型等事情，都希望能够在已有认知和未有认知里发现问题、发现不足。D同学思维广。

既然大家都说得对，都代表了一种优秀的质量理念，那么就不需要取舍了，既要、又要、还要、且要。
所以我们最后的结论就成了：
“质量既是设计出来的，也是测试出来的，还是被逼出来的”，但质量一定不只是测出来的，质量保障不只是测试一种角色的责任，是贯穿研发流程各个角色共同的责任。

3  缺陷发现的时间越早，成本越低

毫无疑问，缺陷被越早的发现，修复的成本就越低。在需求评审阶段就发现需求上的不合理，在技术设计阶段就发现技术方案的问题所在，在测试验证阶段发现系统的bug和产品bug，修复这些环节发现的问题的成本逐渐升高，但如果问题对客后才被发现，修复的成本将是巨大的，可能会影响客户体验和满意度，或造成资损，甚至导致公司名誉受损。

4  测试策略本质上是在质量成本和质量风险之间取得平衡的一种方法

我们知道，程序的执行场景和场景中涉及的数据输入都是无法穷举的，因此测试是不能被穷举的。所以我们需要进行测试方案的设计，通过运用黑盒测试用例设计的等价类、边界值法等，白盒测试用例设计的条件覆盖法、路径覆盖法等从无限的测试数据中选出有效的测试数据，在有限的测试时间内进行有效的测试。

5  开发自测是基本要求和基本素养

我们一直在强调开发自测，无论需求是否有测试接手，开发都必须要自觉地完成自测。作为一名合格的开发，本身就要对自己交付的代码有充分的质量保证，这应该是自上而下地在团队里需要贯彻的思想和共识。

三  实践

ICBU 跨境资金-国际结算团队是 ICBU 质量标准化实践的样板间，我们团队在研发流程各个环节都有严格的质量规范。国际结算团队承接的业务多且复杂，特别是涉及到资金的需求交付，我们都是非常谨慎的。在国际结算团队，一个需求从提出到上线，对于测试接手类的重要需求需要经历如下环节：
需求评审->资源投入评估->技术方案设计评审->开发&联调&自测->测试方案评审 -> 功能预演->测试->发布计划评审-> 灰度-> 全量
对于自测类需求，需要经历如下环节：
需求评审->资源投入评估->技术方案设计评审->开发&联调>自测-> 灰度-> 全量下面将阐述这些环节的规范以及衡量每个环节做得好不好的指标。

1  需求阶段

在需求阶段我们常遇到的问题是，在项目开发过程中，才发现存在未评估到的需求点，如果要实现这些未评估到的需求点，可能会导致项目延期，也无疑会加重项目组成员的压力。为了解决这个问题，我们提出了以下应对机制和规范：

1. 项目开发过程中，发现存在未评估到的需求点，如果不影响到主流程，通过走变更的方式解决。

责任人：识别变更：模块 owner or 模块开发操作变更：PM & PD

2. 大型项目进入开发前，需要再评审一遍细的PRD，如果有UED 变更，需要先准备好设计稿再组织PRD评审；

责任人：PD（组织）、PM（监督&协调）

2  资源投入评估

需求评审结束后，开发和测试同学需要评估投入的开发资源和测试资源，需求PM会拉通各方定下排期，主要包括联调时间、提测时间和发布上线时间，各个节点的时间一旦确定，PM和 TPM将会严格按照这个时间点来推进，一般是不允许延期交付的，除非有特殊原因，比如其它紧急需求临时插入等。
在资源投入评估中，除了定下排期，测试还会评估该需求是开发自测还是测试介入，会有一套评估机制。在国际结算团队，开发测试比是9:1，这意味着测试不可能接手每一个需求，对于一些评估出来没有资金风险、不对客的页面需求，会要求开发自测。总的来说这一环节，最重要的规范是：
1. 拉通各方资源，协调排期 责任人：PM
2. 确定联调时间、提测时间、发布上线时间，接下来PM和TPM 会严格按照这三个节点推进项目责任人：PM 和 TPM
3. 由测试确认是否需要测试接手责任人：QA

衡量这一环节做的好不好的指标是：

1.提测准点率

2.提测通过率

3.发布准点率

3  系分阶段

在进入开发前，必不可少的环节便是技术方案的设计和评审。技术方案评审我们要求团队 master 以及架构师必须参加，并且有一套技术方案设计模板。此环节做得好的话，可以让后面的环节走得事半功倍。
总的来说，技术方案设计会要求开发考虑到以下方面：

1. 目标和背景
2. 功能点及开发人日
3. 系统间和系统内的交互时序图
4. 数据库设计
5. 接口设计（包括提供给前端的接口和提供给业务上下游的接口）
6. 定时任务设计
7. 接口性能评估
8. 兼容性评估（是否兼容旧功能）
9. 灰度方案
10. 系统监控
11. 核对方案
12. 资金安全checkList

如果技术方案里没有详细地描述清楚上述方面的设计，在技术评审时会被打回，改完后再次组织下次的技术方案评审，通过后，才会进入开发。这种方式可以卡住那些在技术方案设计上就有问题的实现，避免到提测后才发现系统设计问题的不可控局面。

4  测分阶段

毫无疑问，详细的测试方案和测试用例评审一来可以让测试同学对本次需求的改动和风险了然于胸，二来可以帮助开发梳理功能点和影响范围，三来可以正式拉通三方（测试、开发、产品）对本次交付功能点的共识。为了达到这个三个目的，我们整理了测试方案设计的模板和规范，要求团队内的测试同学：
1. 在接手超过2天的测试项目时必须要有测试方案和测试用例的评审环节
2. 要在开发技术方案评审后的五天内完成测试方案的评审
总的来说，测试方案设计会要求测试考虑到以下方面：

1. 需要提供给开发的冒烟用例
   
2. 本次需求的功能点及对应的覆盖用例
   
3. 本次需求改动点可能影响的旧功能及回归用例
   
4. 上下游联测方案和时间点
   
5. 可能导致的资损点分析及需要建核对的场景
   
6. 接口性能分析
   
7. 灰度发布方案分析
   
8. 维护并且更新主干用例库

5  开发&联调&自测阶段

在比较大的项目里，比如 xx项目，参与研发的开发同学多达13位，研发时长长达一个月，在长达一个月的研发时间里，如果没有在关键节点及时同步进展，项目的进度和质量很可能是不受控的。xx项目踩了这个坑，没有在关键节点在项目组内同步每日的研发进度，导致问题（项目中中途有人被其他需求插入导致某模块没能按时联调，提测质量差；开发为新人，没能按时提测等）集中在提测节点暴发。基于这个教训，我们进行了复盘，并定下后续在这个环节的规范，即：

1. 进入项目联调环节后，需要发联调日报（PM汇总发出），并每日晨会同步联调进度。

责任人：PM

2.原则：联调前需要先完成域内的自测；

责任人：开发

3.遇到卡点问题，由接口依赖方主动去push被依赖方解决，如果被依赖方没有及时解决，并影响了进度，需要同步风险

责任人：上游开发

4.联调阶段，上游Mock联调或者真实链路联调发送消息，跟对方开发确认消息是否正确，增加确认过程；真实链路联调和mock联调接口不允许有差异。

责任人：下游开发

5. 由测试同学提供冒烟用例给到开发自测，开发必须把冒烟用例的所有场景走完才可以提测

责任人：开发执行、测试监督

6. 发布前单测增量覆盖率需达到60%，单测通过率 100%

责任人：开发执行、测试监督

7.  提前两天后需完成组内CR

责任人：开发

在自测环节，测试会提前提供一份冒烟用例给到开发自测。
我们会要求开发必须把冒烟用例的所有场景走完才可以提测。目前冒烟用例是用语雀文档的形式提供给开发，这是一种线下的方式，不太利于回溯和标准化推广，因此ICBU质量团队在菲尔兹平台上结合 aone 的用例管理提供了线上化的冒烟流程，后续会基于菲尔兹平台提供线上化的冒烟用例及冒烟状态管理。

衡量这一环节做的好不好的指标是：
1. 提测准点率2. 提测通过率3. 自测可发现 bug 率

6  功能预演阶段

在没有提出功能预演这个环节之前，常常会出现开发们提测的功能连页面都打不开或者接口调不通的低质量问题，低质量的提测会导致测试非常被动。为了避免这种问题，我们在团队里提出了功能预演，即在提测前PM需要拉测试和开发一起对提测的版本进行一轮功能预演，保证主流程是可以走通的，这样子可以快速地在提测前就把非常低级的问题快速解决，也让测试同学能有更多的时间测试系统异常流，保证项目的交付质量。
如果功能预演没有通过，提测将会被打回，问题解决后，开发需要再次组织功能预演，并顺延发布时间，我们会在菲尔兹平台上记录提测被打回的原因以及延迟发布的原因，并定期review 数据，对于多次延迟的现象进行复盘，商讨改进方案。

以前很多团队可能都提过提测不通过，那就打回，把问题解决后再提测，但是从来没有提过因此需要顺延的发布时间，导致测试的压力非常大，前面开发的锅丢给了测试加班来兜底。更为严重的是，不少团队认可测试兜底的逻辑。为了纠正这种思想，我们做了不少努力，针对延期的项目，专门组织了项目复盘会议，定下了规范：

1. 预演前需要先完成域间联调
   
2. 功能预演由测试主导，开发需要在场，如果主链路卡住，需要由开发给出下次预演的时间，并顺延发布时间，周知项目组；

责任人：预演-测试；排查-开发；

3. 功能预演出现的问题，如果是bug问题，需要由开发本人去推动解决，如果是数据问题，则由测试去推动
   
4. 环境问题需要完成治理

跟进人：架构师

7  测试阶段

目前超过3天的测试时间的项目，测试同学会发每天发日报，通过日报来及时同步测试进展和风险，同时要求 bug 开发日结。日报模板：
一、项目里程碑

二、进展和问题

三、风险

四、明日计划

比如发票平台的一个日报：

一、项目里程碑

• 11.9-12.28：设计&开发&联调，已完成
• 12.21：发票配置后台功能预演，已完成
• 12.30：开票流程优化功能预演，已完成（延期6.5个工作日）
• 12.22-1.6：线下测试，已完成
• 1.8-1.12：预发回归测试，进行中（延期2个工作日上预发，原计划1.5日）
• 1.13：发布（延期5个工作日，原因：开发人员被其他项目占用资源，进入此项目时间晚）

二、进展和问题

• 线下测试进度：100%
• 预发测试进度：

• 发票配置后台测试进度：100%

• 开票流程优化测试进度：90%

三、风险

1. 项目延期：项目延期至2022.1.13发布，延期5个工作日。 原因：① 开发人员被其他项目占用资源，进入时间晚；② 开发同学前期对工作量评估略少于实际；③xxx项目紧急插入，前端同学需要投入一天。④ 缺陷修复完成时间未如预期，预发提测时间延期2天。
   
2. bug修复

四、明日计划

1. 回归验证 新开票功能遗留缺陷；
2. 回归嵌入式开票流程；
3. 回归原有开票流程。

通过日报触项目组的所有同学（包括开发、产品、业务、测试），可以让大家对目前的测试进度和问题有个清晰的认知，同时如果项目有风险需要延迟，也可以及时周知到产品和业务，方便拉齐大家的预期。目前大家对日报还是非常认同的，后续也会坚持这个规范。

8  发布计划评审

相信不少同学会遇到过这样一种情况，很多场景在预发验收的时候没有问题，一发到线上发现这些场景就走不通了，经过一番排查发现原因是：接口没有多注册、metaq的 topic 没有配置、switch 或 diamond 的开关没有配置好、dts 定时任务没有启用等配置类问题。为了避免这类问题再度发生，我们要求：

在大项目发布前，需要进行发布计划评审，在发布前在项目组内同步一遍准备工作，之后再进行发布。
责任人：项目PM

模板如下：

1. 发布范围

1. 应用范围
2. 发布顺序
   

2. 资源梳理

1. HSF接口
2. 数据库资源
3. 消息资源（metaq）
4. 调度资源（dts）
5. 配置资源（diamond、switch、antx）
   

3. 灰度计划
   
4. 发布过程

1. 预发发布过程
2. 线上发布过程
   

5. 回滚计划
   
6. 跟踪计划

1. 核对
2. 系统监控
3. 服务监控
   

7. 风险控制和注意事项

1. 历史数据兼容
2. 幂等逻辑确认
3. 灰度方案
4. 应急开关

衡量这一环节做的好不好的指标是：1. 线上bug率

9  发布&发布后

发布遵循集团的安全红线
1. beta 至少一个小时，可回滚
2. 业务上可灰度，灰度没问题后再放开到全量用户对于功能发布后的系统跟踪，主要通过系统监控、服务监控、核对来覆盖，当出现异常时，开发和测试会第一时间去关注原因并解决问题。
对于功能发布后的用户体验跟踪，目前主要是通过灰度客户的反馈以及全量后工单的分析。
可以看到最近存在较多工单的业务模块是哪些，从而进行针对性的优化，目前这一块主要是开发在跟进。

10  项目回顾

在大型项目发布后，如果这个项目过程中出现过一些问题，我们一般会要求组织一个项目复盘会议，对项目中出现的问题进行复盘，并商讨出后续的机制和规范，以免后续的项目再踩同样的坑。

通过这种方式，可以不断地完善我们团队研发流程的规范，并及时解决当下存在的问题。

11  和菲尔兹发布平台的结合

菲尔兹平台，定位为对发布进行管控和质量管理，并对开发自测有更多输入和帮助的一个平台。

自测类需求与菲尔兹平台的实践

目前菲尔兹平台与 aone 卡点打通，对于自测类需求，要求开发在发布前需要先完成开发自测，并在平台上提供自测反馈后才能发布到线上。
通过把自测流程线上化，我们希望可以给开发自测提供更多的帮助。

1. 构建主干案例库，做到每个场景有详细的操作步骤，以及一键触发的接口自动化
2. 对于自测类需求，由测试在菲尔兹平台上圈选需要回归的主干用例给到开发执行

我们发现，不少开发只了解部分的业务，或者只知道后端的部分业务逻辑，有时难以评估自己的改动会带来的影响，或者有时想回归某个业务但是不知道怎么操作，为了解决这些问题，我们最近在建立国际结算业务的主干用例库，让开发即使在不熟悉相关的业务的前提下，也能按照我们的用例“傻瓜式操作”地进行回归，从而解决开发自测的痛点。

测试接手类需求与菲尔兹平台的实践

一般测试接手类的需求，需求都比较大，研发周期比较长，参与人员会比较多。目前这类需求菲尔兹平台提供给给我们的能力有：

1. 冒烟流程线上化，测试可以在平台上添加冒烟用例，并由开发标记冒烟状态，由此我们可以统计冒烟通过率
   
2. 提测流程线上化，测试可以在平台上把提测打回，由此我们可以统计提测通过率，从而衡量当前开发提测的质量，并针对性地进行复盘

但对于后续流程，比如测试环节的测试日报、风险同步、发布计划等，目前平台能提供的能力还在探讨中，期待后续。

四  总结

前面给大家阐述了国际结算团队在质量标准化上的一些共识，以及经过前面不少项目复盘总结出来的规范和标准。这些规范和标准定下来后，还是得依靠测试和开发同学在后续的项目中运营、落实、完善并继续优化。我们也在思考，整个研发流程能否都线上化运营，目前还没有好的解决思路，更多的还是依赖人来分析并驱动。