持续坚持原创输出，点击蓝字关注我吧
介绍研发流程主要是给大家一个体感，可以直观感受阿里测试工程师从项目的立项到最终发布经历了哪些过程、做了什么工作。
需求的产生
刚毕业工作那会，认为需求来源于产品，把PD宣讲的产品需求奉为圭臬，很少去质疑，随着工作经验的丰富，逐渐认识到需求的产生其实是来源于市场，PD也只不过是市场需求的“搬运工”和提炼者。
因此，平时做项目的时候，还是要了解下市场的情况，多思考需求的背景、需要解决的问题以及能取得什么产出。
我目前所在的团队做的业务属于中台型的，可以简单理解为服务的“客户”就是上游调用我们服务的团队，这里叫“行业产品”，他们是能直接产生经济效益的，技术层面上来说行业是通过对中台提供的各种微服务进行编排以对外提供某种产品能力。因此， 中台的很多需求来源于行业，至少我这一年来做的项目大多数是配合行业做的，中台另外一部分需求就是来源于“自我革新”，即架构升级。
总结下来中台的需求来源就是行业层需求+中台自我架构升级。因此，中台的建设也存在想完全摆脱业务但又无法摆脱的矛盾。
这种情况难受的不止开发(需要做一些特殊业务的兼容)，对测试来说更难受，线上很容易出现一些意想不到的“惊喜”。这也是当前项目测试中存在的难点，目前也没有很好的办法，只能靠专家经验。
架构设计
架构设计一般是组内的高P来搞，相对于一线干活的低P，他们往往大局观更强，架构设计的更为合理(高p大多工作多年，对系统有深入了解)。
当然架构设计也不是必须的环节，一些不涉及架构变动的项目一线开发同学就足以解决了，高P更多是参与代码Review。
系分评审
大项目会优先评审架构，然后各域评审系分。
系分评审之前，各域会做契约对齐，没问题后才开始评审。
系分评审内容重点是上下游的调用链路变动分析(时序图)，新功能的实现逻辑(代码变动、领域模型变动、数据模型变动)，兼容性分析。
不同的开发写的系分文档质量也不近相同，但系分文档通常包含以下模块：
需求背景
需求分析
实现目标
架构分析
当前架构分析
目标架构分析
上下游依赖分析
数据模型分析
链路变更分析
现状分析
目标链路分析
具体变更流程
兼容性分析
配置变更分析
系分评审的重点是 需求怎么实现，对存量业务的影响分析。
测分评审
在第一家公司的时候，当时写的是测试方案，其实和测试分析算是一个东西的两种不同叫法。测分一般是在系分评审后开始写，通常一天左右可以搞定。测分主要包含以下内容：
需求分析
变更分析(现状、目标时序图、改造功能流程图)
测试场景分析
正常流程
异常流程
幂等分析
风险点分析
兼容性分析
非功能测试
资损分析
测试用例
测分评审内容侧重点在于测试什么、该怎么测、潜在风险点。
开发联调
开发联调一般是上游发起的e2e测试。
通过联调测试验证上下游的契约是否对齐。
联调内容一般是业务的主链路场景。
域内测试/e2e测试
一般是用项目分支提测，特殊情况下，例如项目比较赶时间，也是可以在开发分支提测。
项目分支：用于直接合并到master的分支
开发分支：开发新feature的分支。
域内测试就是单域（服务）测试，例如金融域。需要注意的是单域并非单接口，域和接口是一对多的关系，也就是说单域包含多个接口对外提供不同的服务，只是这些接口业务比较相近，统一划归到某个域了。因此，域内测试可以等同于接口测试，微服务下更多是非Http协议实现的接口，例如基于TCP协议的RPC。所以市面上的接口测试工具，如postman，jmeter都不能直接拿来用了，需要测试同学搭建符合自己需求的测试框架。域内测试重点关注单域功能质量，因此需要mock掉依赖的下游服务。
e2e测试就是通常说的端到端测试，是一种用于测试整个应用程序的流程是否符合预期的测试技术。重点关注输入输出的黑盒测试手段。
e2e测试一般是行业的测试同学(主测试)发起，平台测试需要关注e2e测试过程中的所在域的报错并帮忙排查原因，以及落单的数据是否正确。
平台测试：单域功能的测试同学，负责单域的质量保证。
主测试：一般是行业的同学，整个项目的测试owner，把控项目整体质量，每日同步各平台 测试的进度与风险。
回归测试
回归测试的内容包含 新功能与存量功能的回归。
回归的手段目前有域内自动化case、流量回放工具。
预发布
预发环境一般是产品同学用于测试验证的“生产环境”，预发就是把代码发布到预发环境。
灰度发布
灰度发布也称为金丝雀发布（Canary releas）是版本升级平滑过渡的一种方式，当版本升级时，使部分用户使用新版本，其他用户继续使用老版本，待新版本稳定后，逐步扩大范围把所有用户流量都迁移到新版本上面来。这样可以最大限度地控制新版本发布带来的业务风险，降低故障带来的影响面，同时支持快速回滚。
对于测试来说，灰度过程需要关注下 报警日志，分析下报错原因，确认是否是本期代码变更导致。
生产发布
生产发布，就是将本期代码变更推到全部的生产服务器上，所有用户的请求会走到新代码，至此 整个项目流程也就就结束了。
关于灰度发布vs蓝绿发布区别
灰度发布
灰度发布的介绍可以见上文，这里不做赘述。下面介绍下蓝绿发布。
蓝绿发布
蓝绿发布提供了一种零宕机的部署方式，是一种以可预测的方式发布应用的技术，目的是减少发布过程中服务停止的时间。在保留老版本的同时部署新版本，将两个版本同时在线，新版本和老版本相互热备，通过切换路由权重的方式（非0即100）实现应用的不同版本上线或者下线，如果有问题可以快速地回滚到老版本。
- END -
下方扫码关注 软件质量保障，与质量君一起学习成长、共同进步，做一个职场最贵Tester！
后台回复【测开】获取测试开发xmind脑图
后台回复【加群】获取加入测试社群方式
往期推荐
聊聊工作中的自我管理和向上管理
经验分享｜测试工程师转型测试开发历程
聊聊UI自动化的PageObject设计模式
细读《阿里测试之道》
我在阿里做测开
