1.业务现状
近3年来门店业务快速扩张，门店已到达到了全国范围的几百家 ；前期业务系统架构上为了快速响应业务诉求，系统实现只是为了更快响应业务并没有做很好的系统架构以及相关领域模型规划；随着时间一长，很多问题又逐渐表现出来，如：
（1）门店侧早期由于当时角色比较少，功能比较少，所以很多角色类在代码中写死的；随着系统角色的增多，功能的增多；想要在系统中新增角色时需要将涉及到权限相关的代码中都进行更改，测试还需要进行全量测试，研发成本越来越高，交付周期也越来长；
（2）相同的功能点，在很多个业务场景中都有，但是实现方式不统一，没有全局规划，系统中有多少该功能点很难知道，系统维护越来越难；
（3）门店早期业务指标和数据量比较少，对于系统实现以及性能的要求不高，但是后期数据量大的时候，一些查询功能，查询时就会很慢，用户体验越来越差；
基于以上等问题门店部分业务的重构迫在眉睫。
2.门店重构类型、难点、常用提效手段
3.不同类型重构测试方案
针对不同类型的重构，QA如何快速支持？在测试方案上如何设计与实施呢？下面举两个例子详细介绍一下。
3.1.前后端均重构、业务不变 案例：
以"业绩系统重构"项目进行介绍：
- 重构目的
（1）解决查询时间长问题
- 重构内容
（1）前端查询筛选条件重构，用固定时间维度 取代 随机时间维度
（2）库表结构重构，用更多时间维度数据 取代 天维度数据，用更多管理维度取代 单店员维度
（3）优化组装数据，用并发执行 取代 顺序执行
（4）优化非统计表中数据获取，去掉实时获取数据
- 测试目标
（1）查询结果数据正确性，与原有查询条件一致时，查询结果一致
（2）查询耗时减少
（3）快速高效保障质量
- 测试难点
（1）筛选条件比较多
（2）重构测试内容多，全部条件进行回归
- 测试难点分析
（1）该系统主要是以查询为主，查询比较多，但是更改数据库的场景比较少
（2）如果按照需求上线的方式进行手动测试，测试的时间比较长
- 测试方案
（1）在接口维度进行新老接口数据比对测试
（2）以稳定沙箱环境作为基准环境，进行耗时比对
（3）前端筛选条件变更的部分，以功能测试为主
- 测试过程
（1）准备case
- 接口case1：主要是新老查询条件变更的接口，这一部分接口需要将新的查询条件 与 老的查询条件 一一对应，然后批量生成case；
备注：遍历生成case主要根据查询条件，对查询条件中的每一项值进行遍历；
-
接口case2：主要是新老查询条件未变更的接口，这一部分接口新老查询条件不变，用已有的接口case即可；
-
接口case3：线上已有的请求数据进行多维度的回归，做到case的查漏补缺；
备注：线上请求的入参，主要是通过运维在ng中获取；
（2）比对测试
- 使用diff平台进行批量比对测试
①根据不同的case场景，创建不同的批量接口比对任务，进行执行
②执行成功后，通过查看结果确定case是否比对成功，比对成功，则不需要排查问题，比对失败则需要进一步排查问题所在
③执行失败后，修改完代码后，进行"重新执行"快速回归
- 使用whistle抓包工具查看请求耗时
3.2.前后端重构、业务变化 案例
以"任务中心重构"项目进行介绍：
- 重构目的
（1）满足运营侧任务多样化的诉求
（2）优化任务创建形式
（3）便于任务流程一体化管理
- 重构内容
（1）发布各类型任务
（2）报备逻辑服务迁移，库表迁移
（3）任务反馈、通知
（4）兼容包含业务流程的任务
- 测试目标
（1）保证新任务发布及反馈正确性
（2）任务系统兼容已有流程快速回归
- 测试方案
（1）任务系统包括后台、熊店长APP，且后台与APP的耦合性不高，采取分批提测，分批测试，减少项目整体周期
（2）兼容已有业务流程的任务，整体流程长
- 测试过程
（1）对于业务重构部分，重点在以下三个方面
①冒烟阶段提前diff代码，梳理不同任务类型在创建任务的实现方式
②创建任务完成后，通过日志查询是否在预期时间内发送且消费了延时mq
③前端功能主要通过功能测试执行
（2）业务重构兼容已有业务流程
①已有业务流程的任务，提前梳理触发任务状态流转的节点
②重点关注原有功能流程与本次功能的边界条件
本次需求重点关注：
a.何时触发新的任务状态变更
b.反馈任务落表节点
c.任务结束后，过程中数据如何处理
4.总结
以上通过两个具体的重构场景进行说明，下面总结概括如下：
-
了解需求，确定是哪一种类型的重构需求
-
了解技术实现，明确技术实现方式以及改动范围
-
明确需要整理的case，包括功能测试和接口测试case
-
明确测试方式，批量接口diff、流量回放、手工测试等
-
明确兼容老数据时，过程中数据处理方式
-
兼容老数据时，明确上线后是否需要进行灰度策略
-
兼容老数据时，明确线上流量是否需要新老结果比对，不一致时报警机制