|
背景介绍：公司一个迭代了3年+的业务重构，涉及到中台+业务后端、pc前端、移动端，需要在保证质量的前提下有一定的提高效率。对于这样的项目如果交到大家的手里要怎么做？
接下来我对自己刚结束的项目，做一个简单的自我复盘来和大家探讨一下这样的项目我们怎么做。大家如果有相关的需求可以继续看下去。同时希望大家可以积极发言集思广益，共同进步。
一、项目背景和需求
背景：某电商公司想要收拢业务部门的共同销售渠道的商品创建和编辑，下沉到到中台维护，涉及到后端、pc端、移动端。对于中台来说这是一个通用能力，可以一起收拢到一起去维护，对于业务部门来说可以避免重复造轮子，减重快速发展自己的特色业务。
需求：这个业务毕竟在业务部门已经迭代和维护了3年+，和中台现有业务相比肯定会有一些自己业务的特性。并不是简单的接管业务，相当于把业务部门的商品创建、编辑业务重构了一遍。
二、项目准备期间
本司一个项目需求评审完之后，准备过程有以下关键步骤（中间小谈论不在赘述）：技术方案评审，测试用例评审
技术方案评审
以后端的技术方案评审为例，涉及商品垂直业务部门的后端技术方案评审。我们的流程是怎么样的呢？
1.两边开发对过大概的业务流程之后，开始着手准备技术方案。
2.技术方案准备完之后在自己后端组内内审。
3.内审通过之后开始拉相关业务的测试和开发一起评审，评审过程中针对测试和其他业务开发提出的问题做统一的解答。
4.对于不能马上给出结论的问题会做会议记录，会后讨论过给出答复（发现坑很多的问题的话，可能会重新发起评审）。
测试用例评审
对于这次项目，改动较大怕前期评估不全后边留坑，所以测试打算先写测试方案，然后中台和业务部门的测试一起对测试方案。
1.垂直部门的相关测试根据开发的技术方案，推演相关的业务流程分别写测试方案和影响点。
2.测试内部对测试方案和影响点，列出疑问点然后抛给开发，等开发答复（问题较多，最后建议开发重新技术方案评审）。
3.等开发重新技术方案评审完之后，测试内部梳理完整的业务时序和系统调用图（因为两个业务的开发是分开写技术方案的）。
4.对之前的测试方案细化，编写测试用例，记录在编写用例过程中的小的细节问题。
5.拉业务相关的开发和产品一起测试方案评审，一方面提出自己的问题，拿到答复。另一方面解答开发和产品的问题。
二、测试过程
数据对比脚本
整个业务涉及字段有一百多个，并且之前出现过前端默认字段（0，null，不传等），和后端新增字段的一些默认初始化值不符合预期，导致其他业务方用数据的时候异常导致故障的情况，所以我们要对比不同场景下，字段的存储情况，这样可以避免对商品下游业务产生影响。
1.因为前端调的后端接口已经全部换了，而且还涉及到后续的数据copy业务（数据同步）改动，所以不能通过对比到后端入参去测试该部分。
2.因为流程较长，从业务部门到中台都有相关数据的存储，从核心到边角涉及到多个库的将近10个表的数据存储，所以如果单纯的人肉一句句写sql执行对比的话，效率会很低工作量也会很大。
综上原因，最后决定通过写shell脚本查询表数据，并且对同步数据和原数据做diff，最后这个脚本帮助我们提效很多。
报文对比
前端和后端测试完成之后，后端的默认数据等已经确定过没有问题了。我们在测试移动端的时候会记录相同场景下前端和移动端到后端的报文。然后对报文数据做diff，可以快速定位到移动端的传参不符合预期的字段。
三、风险控制
毕竟是前后端一起重构，不能保证完全没有任何问题，并且重构的业务的已经有很多的用户在线上使用了，一旦出现问题影响会比较大，那么我们是怎么控制风险的呢？
灰度发布
1.配置业务的灰度功能，设置白名单，前端、后端、移动端都读这个白名单数据，在白名单中的话走到新代码，否则继续走老代码，上线后根据情况切流把所有的业务都切到新代码上。
2.配置了白名单，在一定程度上控制了风险，但是会导致测试的复杂度增加，在测试新代码没有问题的前提下，还要保证以下几点：
-对老代码没有影响（上线前的重点——因为刚上线的时候都是走老代码的）。
-从入白名单到切换出白名单（相当于小面积回滚）数据和页面能正常的运行。
-老数据走到新代码能正常的运行。
3.使用全公司通用的灰度发布功能，灰度应用的发布过程，慢慢切流，观察线上日志和用户反馈。
配置监控数据和限流
1.因为业务流程较长，怕最后因为数据异常的时候不好定位问题等，会在代码中添加对应的日志，方便定位问题。另外也会对相应的dubbo接口配置线上监控，出现多少次报错/异常开始报警通知。
2.梳理整个业务流程中关联后端应用的线上部署情况，评估哪个应用处理可能会是整个链路的瓶颈点，然后针对该应用做扩容或者是对流量入口的后端应用配置限流。
过滤应用错误日志
针对该项目中所有后端应用的错误日志，在上线前过滤一遍是否是项目bug或者是异常数据。
四、codereview
中台和业务部门分别组织测试和非项目组开发人员和一起code review，针对review过程中的问题解答或者是记录
六、上线过程
写发布/回滚计划
项目涉及修改的应用较多，在发布前项目组中商品垂直业务的相关开发一起排发布顺序和回滚顺序。然后技术负责人编写发布计划，涉及到发布、回滚顺序发布过程中各个应用的推流计划，以及应用的相关配置和接口的发布。然后组织项目组相关的开发和测试一起review发布计划。
模拟发布过程
测试内部组织在测试环境，根据发布计划和回滚计划，模拟项目的发布和回滚过程（验证该过程对业务的影响）。 | 
转播
