导语
多个旧模块为实现一个需求，涉及到接口级的字段的新增/删除，或者DB表字段的新增/删除，考虑过新老数据在新老模块间的兼容问题吗？或许你会问，会有问题吗？有什么问题？本文主要是针对今年遇到的2个线上新老数据不兼容问题进行分析（由于测试同学忽略了新老数据的兼容测试导致），分析漏测的原因，总结可能会出现新老数据不兼容问题的场景，确定测试点
目录 一. 问题回顾
问题1：两个模块接口交互去掉字段，新老数据不能兼容处理
问题2: 模块A修改对字段的写入值，模块B加入对字段的校验逻辑，未考虑新老数据兼容
二. 测试分析
2.1 发布顺序测试
2.2 新老数据兼容测试
一. 问题回顾
以下2个问题，都是实际在项目中上线时遇到的真实问题，问题的出现，不可否认是漏测导致的，再分析下去，是没有用例，测试思维不够严谨导致的。为什么这个地方思维不严谨，就会导致问题出现呢？有什么特殊的地方？这类场景是什么呢？
问题1：两个模块接口交互去掉字段，新老数据不能兼容处理。
1、需求描述：两个模块之间的接口改动，删除字段ACType，以及删除字段相关逻辑校验。
2、线上问题描述： 无论是先发布前置机模块，还是先发布限流服务模块，都会导致中途出现数据接口交互异常，导致业务流程异常。
如果先发布限流服务，旧前置机发过来的旧数据带字段ACType，新限流服务不再解析，处理完之后返回的rsp是没有字段ACType，而这个字段对旧前置机又是必字段，导致旧前置机校验包发现缺字段报错。同理，先发前置机也会出现同样的问题。
3、线上处理：限流服务增加一个版本，叫兼容版本。如下所示：
先发布兼容限流服务，旧前置机发过来的旧数据带字段ACType，兼容限流服务不再解析，处理完之后返回的rsp是有字段ACType，旧前置机解析正常。
再发布新前置机，新旧前置机发送数据无论带或者不带字段ACType，兼容限流服务都能处理。
最后发布新限流，兼容或者新的限流服务发送数据无论带或者不带字段ACType，新前置机都可以不处理，流程正常运行。
问题2：模块修改对字段的写入值，模块加入对字段的校验逻辑，未考虑新老数据兼容
1、需求描述：涉及改动的2个模块 collection和sched
修改前：一笔数据的处理，先经过受理模块，会插入申请单表时，Frefund_scene=3（取值范围：1-8中，根据入参某字段决定）。再经过collection模块，也会插入申请单表时，Frefund_scene=0，最后经过shced模块，会同时拉取这笔数据在申请单表和总控单表的数据核对后进行处理。
修改后：一笔数据的处理，先经过受理模块，会插入申请单表时，Frefund_scene=3（取值范围：1-8中，根据入参某字段决定）。再经过collection模块，会插入申请单表时，Frefund_scene=3（取值范围：1-8中，根据入参某字段决定），最后经过shced模块，会同时拉取这笔数据在申
请单表和总控单表的数据，核对Frefund_scene一致后进行处理。
2、线上问题描述：
涉及改动的2个模块 collection和sched，发布顺序很明显，先发collection再发shced，那这样就不会有问题了吗？
这个流程，由3个模块组成，属于异步处理流程，每个模块处理完数据之后，都把处理结果保存在db中，等待其他模块去处理，这就会导致数据非实时性，db中会存在之前旧模块产生的旧数据，还未来的及被旧模块处理，就被新模块加载处理出问题。
先发collection，旧数据Frefund_scene=0，旧shced能处理。新数据Frefund_scene=3，旧shced能处理。
再发sched，旧数据Frefund_scene=0，新shced不能处理，会报错，提示数据不一致。新数据Frefund_scene=3，新shced能处理。
3、线上处理：sched增加灰度逻辑上线。增加Frefund_scene=0时不校验业务的逻辑。
二. 测试分析
2.1 发布顺序测试
问题一属于多模块发布顺序问题，那何时需要考虑版本发布顺序呢？首先前提应该是业务涉及多个模块，模块间接口字段变更或新增或者模块间逻辑存在依赖时，需要考虑模块的发布顺序。原则上 “先发被依赖方（底层），再发依赖方（上层）。
当两个模块存在相互依赖的情况下时，会出现无论怎么发布都有问题的情况，这时可以为接触相互依赖，在某个模块中增加灰度逻辑或者增加兼容版本进程处理
2.2 新老数据兼容测试
问题二就属于典型的新老业务数据不兼容的问题。那什么是新数据，什么是老数据呢？
定义： 新数据：新版本产生的数据；老数据：发布前旧版本产生的数据。
原因: 模块之间交互是间接的，如通过DB进行交互，或者通过一些缓存，共享内存进行交互都有可能会产生旧版本产生的数据，新版本可能无法消费。
