背景：
群组微服务重构想法上半年就开始了，目前老群组服务除了代码设计不合理，服务部署无法启动也是痛点。研发侧发起技术重构。
测试角度来说我这边痛点有三个：
-
业务不熟悉也没有完整有效case->有哪些功能点，那些写在PHP，那些微服务实现等
-
研发产品人员变化，熟悉人都不在了。
-
测试周期比较长（跟版需求优先级高于群组微服务）
第一阶段首次提测
理想微服务重构
接口名称一样，缓存key和查询数据逻辑都一样，这样美滋滋的，我们测试起来比较方便。
实际服务重构
接口名称不同、缓存key不同，甚至mysql还有扩表。
为啥出现这种情况呢：
-
历史负担：之前设计不合理这次一起改了，数据存储也不应以前的了。
-
他人接手：你接受写了90%已经改了，不能在开发了，遇到问题就修复（这个属于这个原因）
测试问题
-
mysql扩字段：老服务能不能兼容会不会有功能报错，你需要回归老服务功能。
-
缓存key更换：数据同步问题，线上数据同步过去，你需要线上有数据账号在新服务跑一遍。有问题修数据，老服务不能修代码的。
-
接口名更换：app测试服务端在nginx可以做映射，对于app端无感的。但是服务内部调用，PHP->群组服务，cms调用群组服务，这些都需要你去找研发确认（非常消耗时间）。
总结：事情比较多，周期比较长，中间断断续续的。自己把握好。以上你都做完了，但是核心问题，上线步骤你没定还是有问题。
问题：我和研发约定服务端全上，不是接口先上一部分，观察3天，继续上线（可以理解接口数量维度灰度）。
好处：就是风险可控不至于出现大规模的线上问题。
坏处：有走新的，又有走老的，数据上线之前同步；过程才生数据有问题新老服务不同步就有问题了。测试场景不会覆盖这种复杂场景，需要提前约定。
问题缺陷
- 提测接口客户端调用报错，典型还是字段类型问题，因为客户端不动，之前入参类型必须一致的（服务端没有用客户端看的习惯，直接curl或者用.doc测试了）
举例：
2.服务内部调用错误或者数据写入异常
3.灰度配置和数据报错：
这类基本都是host配置错了，数据库配置错了->所以服务重构灰度一样重新走一遍。
第二阶段 redis双写
为了解决阶段一的问题，在需要切换新老服务&&功能正常，做了数据双写（可以理解二次开发和提测）：
可以理解为重新再测试一遍，因为涉及所有接口逻辑。
测试方法：调用新服务post接口 调用对应get类型接口查看返回，切换到老服务接口对比返回。->这种服务重构这种方法很快，一个个缓存自己查询，太抽象了，可能查的也不对。
测试问题
1.缓存更新有误
2.mysql错误或者host配置错误
更新db异常和host配置错误：
3.依赖其他消费任务未启动
ps:这一类问题一般存在于送礼升级啊，干其他任务获取积分.
第三阶段 上线
目前上线按照接口一个个去切换
-
一般情况优先切换读取接口-->测试准备又数据账号，切换以后你要看下新服务能不能取到。
-
核心的表单接口->验证接口功能。
-
全量更新。
上线以后除了整体回归以外->你要看下线上大V的用户群组看看对不对->关注线上反馈。
测试遗漏
1.PHP上线过晚
按照研发约定微服务上线一周以后在上线PHP，原因特别简单PHP上线频繁，业务很多，需要群组微服务很稳定在切。我原计划这周上线，后面因为发版延期和我手里新包业务，我想推迟到次周的周1，周五回归65发现了一些调用PHP接口问题，所以周五上线了。
反思：还是要尽快上，有空直接上线，不会影响会有一些。
2.群消息通知缺失
测试场景：设置管理员群里未通知消息。
服务端调用消息两种类型：
根据场景需要各自调用即可。
我们目前产品：
1.设置身份管理员或者发送奖励的时候基本群通知消息。
2.邀请加入，申请加入这些都是在消息助手里面。
问题反思：在回归用例里面有图，我粗糙了，就看更新redis和mysql成功了。忽略消息发送。
经验总结：
我自己理解上面整个流程大体分成三个阶段：
1、新服务功能测试
2、老数据新服务兼容
3、规避风险上线流程约定（双写灰度一段时间，还是一次切换）
按照上面流程走，P0问题肯定不会有也不会有事故，剩下精细化测试细节了。
chatGTP意见：
比如说 老数据，新服务维度我觉得它回答很好
