系统重构迫在眉睫，测试方案助力提效

 

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抓包工具查看请求耗时 

-   整体效果

通过批量生成case、批量diff、快速回归的方式
RD侧：自测过程中，节省人力 2人日；
QA侧：原需求测试时间共计15人日，节省人力8人日；
大大缩短了整个项目的交付周期。

3.2.前后端均重构，业务变化案例

以“任务中心重构”项目进行介绍：

-   重构目的

（1）满足运营侧任务多样化的诉求

（2）优化任务创建形式

（3）便于任务流程一体化管理

-   重构内容

（1）发布各类型任务

（2）报备逻辑服务迁移，库表迁移

（3）任务反馈、通知

（4）兼容包含业务流程的任务

-   测试目标

（1）保证新任务发布及反馈正确性

（2）任务系统兼容已有流程快速回归

-  测试方案

（1）任务系统包括后台、熊店长APP，且后台与APP的耦合性不高，采取分批提测，分批测试，减少项目整体周期

（2）兼容已有业务流程的任务，整体流程长

-   测试过程

（1）对于业务重构部分，重点在以下三个方面

   ①冒烟阶段提前diff代码，梳理不同任务类型在创建任务的实现方式

②创建任务完成后，通过日志查询是否在预期时间内发送且消费了延时mq

③前端功能主要通过功能测试执行

（2）业务重构兼容已有业务流程

①已有业务流程的任务，提前梳理触发任务状态流转的节点

②重点关注原有功能流程与本次功能的边界条件

本次需求重点关注：

a.何时触发新的任务状态变更

b.反馈任务落表节点

c.任务结束后，过程中数据如何处理

-   整体效果

通过提前diff代码，梳理新业务流程、梳理兼容已有业务流程、分批提测的方式

QA侧：老业务流程测试需要10人日，节省人力3人日；
整体上线时间缩短3~4天。

4.总结

以上通过两个具体的重构场景进行说明，下面总结概括如下：

• 了解需求，确定是哪一种类型的重构需求

• 了解技术实现，明确技术实现方式以及改动范围

• 明确需要整理的case，包括功能测试和接口测试case

• 明确测试方式，批量接口diff、流量回放、手工测试等

• 明确兼容老数据时，过程中数据处理方式

• 兼容老数据时，明确上线后是否需要进行灰度策略

• 兼容老数据时，明确线上流量是否需要新老结果比对，不一致时报警机制

 

总结：

感谢每一个认真阅读我文章的人！！！

作为一位过来人也是希望大家少走一些弯路，如果你不想再体验一次学习时找不到资料，没人解答问题，坚持几天便放弃的感受的话，在这里我给大家分享一些自动化测试的学习资源，希望能给你前进的路上带来帮助。

软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。

 

          视频文档获取方式：
这份文档和视频资料，对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！以上均可以分享，点下方小卡片即可自行领取。