系统重构迫在眉睫，测试方案助力提效
【章节】
业务现状
门店重构类型、难点、常用提效手段
不同类型重构测试方案
3.1.前后端均重构，业务不变案例
3.2.前后端均重构，业务变化案例
总结
1.业务现状
2.门店重构类型、难点、常用提效手段
通过以上提效手段明显缩短测试周期，实现项目快速交付。
3.不同类型重构测试方案
3.1.前后端均重构，业务不变案例
接口case1：主要是新老查询条件变更的接口，这一部分接口需要将新的查询条件 与 老的查询条件 一一对应，然后批量生成case；
接口case2：主要是新老查询条件未变更的接口，这一部分接口新老查询条件不变，用已有的接口case即可； 接口case3：线上已有的请求数据进行多维度的回归，做到case的查漏补缺；
- 整体效果
通过批量生成case、批量diff、快速回归的方式
RD侧：自测过程中，节省人力 2人日；
QA侧：原需求测试时间共计15人日，节省人力8人日；
大大缩短了整个项目的交付周期。
3.2.前后端均重构，业务变化案例
- 整体效果
通过提前diff代码，梳理新业务流程、梳理兼容已有业务流程、分批提测的方式
QA侧：老业务流程测试需要10人日，节省人力3人日；
整体上线时间缩短3~4天。
4.总结
以上通过两个具体的重构场景进行说明，下面总结概括如下：
了解需求，确定是哪一种类型的重构需求
了解技术实现，明确技术实现方式以及改动范围
明确需要整理的case，包括功能测试和接口测试case
明确测试方式，批量接口diff、流量回放、手工测试等
明确兼容老数据时，过程中数据处理方式
兼容老数据时，明确上线后是否需要进行灰度策略
兼容老数据时，明确线上流量是否需要新老结果比对，不一致时报警机制