背景：

群组微服务重构想法上半年就开始了，目前老群组服务除了代码设计不合理，服务部署无法启动也是痛点。研发侧发起技术重构。

测试角度来说我这边痛点有三个：

1. 业务不熟悉也没有完整有效case->有哪些功能点，那些写在PHP，那些微服务实现等

2. 研发产品人员变化，熟悉人都不在了。

3. 测试周期比较长（跟版需求优先级高于群组微服务）

第一阶段首次提测

理想微服务重构

接口名称一样，缓存key和查询数据逻辑都一样，这样美滋滋的，我们测试起来比较方便。

实际服务重构

接口名称不同、缓存key不同，甚至mysql还有扩表。

为啥出现这种情况呢：

1. 历史负担：之前设计不合理这次一起改了，数据存储也不应以前的了。

2. 他人接手：你接受写了90%已经改了，不能在开发了，遇到问题就修复（这个属于这个原因）

测试问题

1. mysql扩字段：老服务能不能兼容会不会有功能报错，你需要回归老服务功能。

2. 缓存key更换：数据同步问题，线上数据同步过去，你需要线上有数据账号在新服务跑一遍。有问题修数据，老服务不能修代码的。

3. 接口名更换：app测试服务端在nginx可以做映射，对于app端无感的。但是服务内部调用，PHP->群组服务，cms调用群组服务，这些都需要你去找研发确认（非常消耗时间）。

总结：事情比较多，周期比较长，中间断断续续的。自己把握好。以上你都做完了，但是核心问题，上线步骤你没定还是有问题。

问题：我和研发约定服务端全上，不是接口先上一部分，观察3天，继续上线（可以理解接口数量维度灰度）。

好处：就是风险可控不至于出现大规模的线上问题。

坏处：有走新的，又有走老的，数据上线之前同步；过程才生数据有问题新老服务不同步就有问题了。测试场景不会覆盖这种复杂场景，需要提前约定。

问题缺陷

1. 提测接口客户端调用报错，典型还是字段类型问题，因为客户端不动，之前入参类型必须一致的（服务端没有用客户端看的习惯，直接curl或者用.doc测试了）

举例：

2.服务内部调用错误或者数据写入异常

3.灰度配置和数据报错：

这类基本都是host配置错了，数据库配置错了->所以服务重构灰度一样重新走一遍。

第二阶段 redis双写

为了解决阶段一的问题，在需要切换新老服务&&功能正常，做了数据双写（可以理解二次开发和提测）：

可以理解为重新再测试一遍，因为涉及所有接口逻辑。

测试方法：调用新服务post接口 调用对应get类型接口查看返回，切换到老服务接口对比返回。->这种服务重构这种方法很快，一个个缓存自己查询，太抽象了，可能查的也不对。

测试问题 

1.缓存更新有误

2.mysql错误或者host配置错误

更新db异常和host配置错误：

3.依赖其他消费任务未启动

ps:这一类问题一般存在于送礼升级啊，干其他任务获取积分.

第三阶段 上线

目前上线按照接口一个个去切换

1. 一般情况优先切换读取接口-->测试准备又数据账号，切换以后你要看下新服务能不能取到。

2. 核心的表单接口->验证接口功能。

3. 全量更新。

上线以后除了整体回归以外->你要看下线上大V的用户群组看看对不对->关注线上反馈。

测试遗漏

1.PHP上线过晚

按照研发约定微服务上线一周以后在上线PHP，原因特别简单PHP上线频繁，业务很多，需要群组微服务很稳定在切。我原计划这周上线，后面因为发版延期和我手里新包业务，我想推迟到次周的周1，周五回归65发现了一些调用PHP接口问题，所以周五上线了。

反思：还是要尽快上，有空直接上线，不会影响会有一些。

2.群消息通知缺失

测试场景：设置管理员群里未通知消息。

服务端调用消息两种类型：

根据场景需要各自调用即可。

我们目前产品：

        1.设置身份管理员或者发送奖励的时候基本群通知消息。

        2.邀请加入，申请加入这些都是在消息助手里面。

问题反思：在回归用例里面有图，我粗糙了，就看更新redis和mysql成功了。忽略消息发送。

经验总结：

我自己理解上面整个流程大体分成三个阶段：

1、新服务功能测试

2、老数据新服务兼容

3、规避风险上线流程约定（双写灰度一段时间，还是一次切换）

按照上面流程走，P0问题肯定不会有也不会有事故，剩下精细化测试细节了。

chatGTP意见：

比如说 老数据，新服务维度我觉得它回答很好