要说测试开发们最不想做什么事？那肯定是非重构莫属。
为什么？因为重构意味着程序员要亲自回想起曾经对这个测试平台底层所有代码所有函数所有层所有模块所有功能 全都要重新思考一遍。
先不说这个成本已经接近重新开发一套项目，就单说让人再次仔细的回忆一遍曾经的噩梦，就足以让人崩溃。
而领导一般认识不到这些，在测试平台开发之初，会让你尽快做起来，先着急用。等用的不错了，然后再给你提各种升级需求，说不定哪个需求就正好需要对平台的底层进行重构了。
接下来就看要具体怎么做才能高效又安全，最主要的是省脑细胞！
1. 明确重构的目的，真实的需求！
注意，这里是真实的需求，对比于原始需求，要更加的深度剖析，了解用户的真实目的。注意这个目的是用户眼里看到的，并不一定是对于项目代码也是如此。
可能你没懂这个意思，我举个例子吧：用户希望你的平台的数据全部分成多个组，正常的从肉眼观测的理解是 分成多个组的数据，存放在不同的地方。 而实际上要做的是在原数据库中，给这些数据打上不同的标签，然后前端显示的时候，区分标签来显示即可。而这就是真实的需求。
2. 对整个项目进行分层统计
先对项目进行分层，比如数据层，视图层，业务层，物理文件层，前端组件等。然后对每层的每个数据开始先统计出，是否需要改动，怎么改动？
比如数据层，就是研究所有的数据表，哪些表需要改。先不要着急动手，先用笔记下来。因为重构这种事比较重大，万一改一半发现不对，那就真的要遭了。
然后是业务层，开始遍历所有函数，看是否需要修改。这里有个简单的方案是先对所有函数按照 “增、删、改、查、特殊功能” 进行分类。然后大致的思考一下本次重构着重涉及哪些功能类的。比如我上面举的例子，给数据进行分组，其实就是打上不同得病标签。那么分类考虑就是：
1. 增 ：是需要打标签，所以需要修改
2. 查：需要按照标签区分，所以需要修改
3. 改：如果标签可以改，那么就需要动。否则不用改。
4. 删：删除时候根本无需看标签，只看数据id，那么就不用动。
3. 数据链路传输上，保证上下游通顺。
接上条，我们把每层的每个函数/模块都思考一遍之后，接下来要看的就是他们这些模块/层级之间是否能够衔接顺畅了。
所以要在数据的传输过程中着重观察新增加/减少的字段，比如路由控制器中的参数，还比如各个接口的请求参数，比如后台和前端的数据流转，比如前端vue各组件之间的数据交互。
4. 脏数据问题
在这种大规模的重构下，脏数据是很难避免的。尤其是关注旧数据，要详细思考旧数据在新的架构上，能否正常使用。比如你新增了数据库表的某字段，那么之前的数据没有这个字段，如果你又不设计默认值的话。那么大概率都会变成None型，而你的前后端从未考虑过会出现None,也没有对应的处理。自然就会报错，这些旧数据也就变成脏数据了。
你要么一开始设计好默认值，要么设计好后面的sql跑批脚本。
然后就是新旧数据的对比测试问题，要保证新创建出的数据和旧数据完全一样的表现。这个测试起来比较方便的办法是，两个终端，一个旧数据，一个新数据，对比测试。表现不同即算bug。
5. 完全回归测试
大家要知道，大型重构后，bug是必有的，这点不用存疑。企业级的软件甚至会爆发出上百个大小bug。就算是简单的测试平台来说，有十几个因为这次重构出现的Bug都太正常了。
所以调整好心态，不要怕麻烦，进行一轮完全回归测试是非常必要的！
最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走
这些资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。希望对大家有所帮助…….
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
