简介：最近部门在推品质标准化，通过品质标准化，推动品质内建，从而进步研发部门的交付品质，作者深度参加其中，并在推动过程中总结了一些教训以及思考，在此通过以下定义、共识、实际三个大方向和大家分享一下。
作者 | 静艺
起源 | 阿里技术公众号
最近部门在推品质标准化，通过品质标准化，推动品质内建，从而进步研发部门的交付品质，我也深度参加其中，并在推动过程中总结了一些教训以及思考，在此通过以下定义、共识、实际三个大方向和大家分享一下。
一 定义
1 品质标准化
何为品质标准化？用个不太失当的比喻，大家都晓得工厂的流水线作业，每个地位上的人或者机器要做什么都是提前标准好、定义好的，流水线上的商品从原材料到成品通过的都是同一套流程，因而成品间的品质不会相差太远。研发流程和流水线作业有肯定的相似性。咱们心愿通过标准化各条业务线的研发流程，以做的比拟好的业务线作为规范样板间，标准出一套标准化的流程，并实用到其它业务线，从而使各条业务线都能进行高质量的交付。
2 品质内建
不少研发团队的同学都认为品质都是靠测试同学去守护的，会认为产品呈现了品质问题，是测试的锅，这是对测试工作和品质保障的一种狭窄的意识。测试同学是品质的守护神，可是品质不能只靠测试同学在最初一环去兜底。想要给用户交付高质量的产品和体验，必须是在研发流程各个环节都恪守品质标准，在需要评审、方案设计、开发、自测环节上的产品、开发、测试同学都要有品质意识并严格执行品质标准，这就是品质内建。
3 交付品质
交付品质蕴含零碎品质和产品体验两局部。零碎品质指的是零碎的性能齐备性、零碎的稳定性和健壮性，产品体验是指客户应用此产品时是否有丝滑的体验。
二 共识
要让研发流程中的各个角色都违心去践行一套对立的规范和标准，必不可少的条件是各个角色意识形态上的对立。只有团队的思维统一了，规范和标准能力被推动并落实。在推动 ICBU 跨境资金-国内结算团队标准化建设的过程中，咱们团队从上到下首先在以下观点下达成了高度对立。
1 品质不只是测进去的
在知乎上看到针对“品质是被设计进去的，还是被测进去的”问题有一个探讨，感觉写的挺好的，从不同角度剖析了这个命题，我把它摘抄进去，针对“品质之道”的根源之争，大家的发言很踊跃，我摘抄了几个具备代表性的：
- A同学：我认为品质是设计进去的，在设计上思考的各种非性能品质数据，都会落地到代码中。设计的优化会一直的驱动零碎品质的优化。
- B同学：我认为品质是测试进去的，设计的货色能够防止已知的问题，但在理论测试的过程中，还是会发现其余未思考到的问题，例如兼容性问题，你能提前通过设计预防吗？所以测试发现问题，问题驱动品质晋升。
- C同学：听完B同学的发言，我更深信了品质是设计进去的。在一直的BUG驱动下，咱们打补丁式做进去的零碎，品质会更好吗？打补丁解一时之急，而后续系统性的设计、重构、降级，才是晋升品质的关键点。所以...
- D同学：如果站到产品层面，咱们会怎么去定义产品好不好？在咱们定义产品好坏的品质模型里，很可能会蕴含软件研发相干的非性能品质属性(ISO9126)，可能会包含产品舆情、竞品比照中挖掘出的货色。例如，咱们去定义一款内容举荐产品的好坏，除了“内容不反复”、“多样性”等维度外，“是否反对分享”、“是否反对点赞”也会成为品质好坏的评判规范，新性能上线、满足需要，用户就会认为产品好。咱们的认知会一直降级，“好”的规范也会有更高的要求。用户无时无刻不在应用、测试、反馈，让品质一直变好。
2 既要、又要、还要、且要
上述的四位同学的观点，代表了不同的品质理念和谋求：
- 谋而后动的观点：无论是对需要的二义性剖析、对设计中UML图的流程剖析、时序剖析、状态剖析，都是心愿可能磨刀不误砍柴工、降低成本。A同学说得对。
- 摸索式测试的观点：无论是保障在设计变成代码的过程中是否100%的实现翻译，还是在测试的过程中受到启发认为应该写下更多的逻辑代码，都是心愿所见即所得，想人之未想。B同学说得也对。
- 技术债的观点：无论是对前段时间的补丁代码进行重构，还是对系统进行架构的降级，还是对基建能力进行优化，都是心愿可能打好底盘，走的更远，走得更稳。C同学靠谱。
- 继续改良的观点：无论是做竞品剖析、舆情剖析、线上被动检测、监控、产品质量模型等事件，都心愿可能在已有认知和未有认知里发现问题、发现有余。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
掂量这一环节做的好不好的指标是：
- 提测准点率
- 提测通过率
- 公布准点率
3 系分阶段
在进入开发前，必不可少的环节便是技术计划的设计和评审。技术计划评审咱们要求团队 master 以及架构师必须加入，并且有一套技术方案设计模板。此环节做得好的话，能够让前面的环节走得事倍功半。
总的来说，技术方案设计会要求开发思考到以下方面：
- 指标和背景
- 性能点及开发人日
- 零碎间和零碎内的交互时序图
- 数据库设计
- 接口设计（包含提供给前端的接口和提供给业务上下游的接口）
- 定时工作设计
- 接口性能评估
- 兼容性评估（是否兼容旧性能）
- 灰度计划
- 系统监控
- 核查计划
- 资金平安checkList
如果技术计划里没有具体地形容分明上述方面的设计，在技术评审时会被打回，改完后再次组织下次的技术计划评审，通过后，才会进入开发。这种形式能够卡住那些在技术方案设计上就有问题的实现，防止到提测后才发现零碎设计问题的不可控场面。
4 测分阶段
毫无疑问，具体的测试计划和测试用例评审一来能够让测试同学对本次需要的改变和危险了然于胸，二来能够帮忙开发梳理性能点和影响范畴，三来能够正式拉通三方（测试、开发、产品）对本次交付性能点的共识。为了达到这个三个目标，咱们整顿了测试方案设计的模板和标准，要求团队内的测试同学：
1、在接手超过2天的测试项目时必须要有测试计划和测试用例的评审环节
2、要在开发技术计划评审后的五天内实现测试计划的评审
总的来说，测试方案设计会要求测试思考到以下方面：
- 须要提供给开发的冒烟用例
- 本次需要的性能点及对应的笼罩用例
- 本次需要改变点可能影响的旧性能及回归用例
- 上下游联测计划和工夫点
- 可能导致的资损点剖析及须要建核查的场景
- 接口性能剖析
- 灰度公布计划剖析
- 保护并且更新骨干用例库
5 开发&联调&自测阶段
在比拟大的我的项目里，比方 xx我的项目，参加研发的开发同学多达13位，研发时长长达一个月，在长达一个月的研发工夫里，如果没有在要害节点及时同步停顿，我的项目的进度和品质很可能是不受控的。xx我的项目踩了这个坑，没有在要害节点在项目组内同步每日的研发进度，导致问题（我的项目中中途有人被其余需要插入导致某模块没能按时联调，提测品质差；开发为新人，没能按时提测等）集中在提测节点暴发。基于这个教训，咱们进行了复盘，并定下后续在这个环节的标准，即：
1.进入我的项目联调环节后，须要发联调日报（PM汇总收回），并每日晨会同步联调进度。
责任人：PM
2.准则：联调前须要先实现域内的自测；
责任人：开发
3.遇到卡点问题，由接口依赖方被动去push被依赖方解决，如果被依赖方没有及时解决，并影响了进度，须要同步危险
责任人：上游开发
4.联调阶段，上游Mock联调或者实在链路联调发送音讯，跟对方开发确认音讯是否正确，减少确认过程；实在链路联调和mock联调接口不容许有差别。
责任人：上游开发
5.由测试同学提供冒烟用例给到开发自测，开发必须把冒烟用例的所有场景走完才能够提测
责任人：开发执行、测试监督
6.公布前单测增量覆盖率需达到60%，单测通过率 100%
责任人：开发执行、测试监督
7.提前两天后需实现组内CR
责任人：开发
在自测环节，测试会提前提供一份冒烟用例给到开发自测。
咱们会要求开发必须把冒烟用例的所有场景走完才能够提测。目前冒烟用例是用语雀文档的模式提供给开发，这是一种线下的形式，不太利于回溯和标准化推广，因而ICBU品质团队在菲尔兹平台上联合 aone 的用例治理提供了线上化的冒烟流程，后续会基于菲尔兹平台提供线上化的冒烟用例及冒烟状态治理。
掂量这一环节做的好不好的指标是：
- 提测准点率
- 提测通过率
- 自测可发现 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%
三、危险
- 我的项目延期：我的项目延期至2022.1.13公布，延期5个工作日。 起因：① 开发人员被其余我的项目占用资源，进入工夫晚；② 开发同学后期对工作量评估略少于理论；③xxx我的项目紧急插入，前端同学须要投入一天。④ 缺点修复实现工夫未如预期，预发提测工夫延期2天。
- bug修复
四、明日打算
- 回归验证 新开票性能遗留缺点；
- 回归嵌入式开票流程；
- 回归原有开票流程。
通过日报触项目组的所有同学（包含开发、产品、业务、测试），能够让大家对目前的测试进度和问题有个清晰的认知，同时如果我的项目有危险须要提早，也能够及时周知到产品和业务，不便拉齐大家的预期。目前大家对日报还是十分认同的，后续也会保持这个标准。
8 公布打算评审
置信不少同学会遇到过这样一种状况，很多场景在预发验收的时候没有问题，一发到线上发现这些场景就走不通了，通过一番排查发现起因是：接口没有多注册、metaq的 topic 没有配置、switch 或 diamond 的开关没有配置好、dts 定时工作没有启用等配置类问题。为了防止这类问题再度产生，咱们要求：
在大我的项目公布前，须要进行公布打算评审，在公布前在项目组内同步一遍筹备工作，之后再进行公布。
责任人：我的项目PM
模板如下：
1、公布范畴
a.利用范畴
b.公布程序
2、资源梳理
a.HSF接口
b.数据库资源
c.音讯资源（metaq）
d.调度资源（dts）
e.配置资源（diamond、switch、antx）
3、灰度打算
4、公布过程
a.预发公布过程
b.线上公布过程
5、回滚打算
6、跟踪打算
a.核查
b.系统监控
c.服务监控
7、危险管制和注意事项
a.历史数据兼容
b.幂等逻辑确认
c.灰度计划
d.应急开关
掂量这一环节做的好不好的指标是：
线上bug率
9 公布&公布后
公布遵循团体的平安红线
beta 至多一个小时，可回滚
业务上可灰度，灰度没问题后再放开到全量用户
对于性能公布后的零碎跟踪，次要通过系统监控、服务监控、核查来笼罩，当出现异常时，开发和测试会第一工夫去关注起因并解决问题。
对于性能公布后的用户体验跟踪，目前次要是通过灰度客户的反馈以及全量后工单的剖析。
能够看到最近存在较多工单的业务模块是哪些，从而进行针对性的优化，目前这一块次要是开发在跟进。
10 我的项目回顾
在大型项目公布后，如果这个我的项目过程中呈现过一些问题，咱们个别会要求组织一个我的项目复盘会议，对我的项目中呈现的问题进行复盘，并切磋出后续的机制和标准，免得后续的我的项目再踩同样的坑。
通过这种形式，能够一直地欠缺咱们团队研发流程的标准，并及时解决当下存在的问题。
11 和菲尔兹公布平台的联合
菲尔兹平台，定位为对公布进行管控和品质治理，并对开发自测有更多输出和帮忙的一个平台。
自测类需要与菲尔兹平台的实际
目前菲尔兹平台与 aone 卡点买通，对于自测类需要，要求开发在公布前须要先实现开发自测，并在平台上提供自测反馈后能力公布到线上。
通过把自测流程线上化，咱们心愿能够给开发自测提供更多的帮忙。
构建骨干案例库，做到每个场景有具体的操作步骤，以及一键触发的接口自动化
对于自测类需要，由测试在菲尔兹平台上圈选须要回归的骨干用例给到开发执行
咱们发现，不少开发只理解局部的业务，或者只晓得后端的局部业务逻辑，有时难以评估本人的改变会带来的影响，或者有时想回归某个业务然而不晓得怎么操作，为了解决这些问题，咱们最近在建设国内结算业务的骨干用例库，让开发即便在不相熟相干的业务的前提下，也能依照咱们的用例“傻瓜式操作”地进行回归，从而解决开发自测的痛点。
测试接手类需要与菲尔兹平台的实际
个别测试接手类的需要，需要都比拟大，研发周期比拟长，参加人员会比拟多。目前这类需要菲尔兹平台提供给给咱们的能力有：
- 冒烟流程线上化，测试能够在平台上增加冒烟用例，并由开发标记冒烟状态，由此咱们能够统计冒烟通过率
- 提测流程线上化，测试能够在平台上把提测打回，由此咱们能够统计提测通过率，从而掂量以后开发提测的品质，并针对性地进行复盘
但对于后续流程，比方测试环节的测试日报、危险同步、公布打算等，目前平台能提供的能力还在探讨中，期待后续。
四 总结
后面给大家论述了国内结算团队在品质标准化上的一些共识，以及通过后面不少我的项目复盘总结进去的标准和规范。这些标准和规范定下来后，还是得依附测试和开发同学在后续的我的项目中经营、落实、欠缺并持续优化。咱们也在思考，整个研发流程是否都线上化经营，目前还没有好的解决思路，更多的还是依赖人来剖析并驱动。
原文链接
本文为阿里云原创内容，未经容许不得转载。