代码重构测试不仅仅考虑的是基本功能的测试，还需要关注性能以及缓存，环境双跑等一系列的测试内容。
为什么要代码重构
当产品功能越来越复杂，很多代码的设计会出现偏差，或者因为一些垃圾代码的产生，导致代码的可读性变差，又或是因为提升产品的性能，所以很多开发人员会进行代码重构的工作。
代码重构的种类
代码重构有很多原因触发，我们现在讨论的是因为性能的差别，实现python—>golang开发语言变更的重构。
代码重构的测试方案
很多人对于代码重构，其实内心是拒绝的，因为代码重构的质量是一个很大的风险点，如何把这个风险降到最低，依靠的不仅仅是开发的代码能力和单元测试的覆盖率，测试工作在这个时候的重要性就展现出来了。所以，对于代码重构的测试，以下几个方面是必不可少的：
1） 代码重构前后的功能对比测试
代码重构的最重要也是最基本的一点，就是重构后的功能和重构前一致，正常情况下，重构前后的功能并未增加，因此没有新增测试用例，这个时候只需将重构前后代码在已有的回归测试用例执行情况保持一致，这就可以证明重构后产品的基本功能是正确的。但是这个依赖于已存在的回归测试用例的完整性，也就是用例的覆盖率，如果回归用例没有做到功能全覆盖，这个时候仅执行回归测试用例是不够的，还需要深入了解产品的需求设计，开发实现，对于当前产品的每个功能做到全覆盖测试。总之，对比测试，就是要做到产品的所有功能的全覆盖对比测试。
2） 代码重构前后的性能对比测试
文章一开始就提到，这次是因为性能的差别触发的代码重构的测试，所以代码重构前后的性能对比测试则是重中之重，如果性能得不到大幅度的提升，考虑到时间、人力等方面的因素，重构则没有很大的意义。一般情况产品性能会关注两个方面，一个是一定时间的压力测试数据，另一个就是当前产品的稳定性情况。压力测试在相同服务器配置稳定的测试环境下，重构前后代码的95%的响应时间及最优的qps值，稳定性测试则需要观测至少24小时以上的执行时间，对于服务器的CPU，内存等各个性能指标的监控。性能测试不仅仅是利用自动化测试工具去并发或者无限循环某些测试用例，对于性能测试的方案是需要反复验证然后及时作出调整，并对测试数据作出分析，这个是代码重构测试中最花费精力和时间的一部分测试。在重构前后的性能测试中，测试方案和测试数据分析方法需保持一致，这样得到的分析结果才有说服力。
重构测试的注意点
完成了上面两部分测试，基本上可以判定重构后的代码的基本功能和性能都是可以满足上线要求的，但是，这样真的就可以上线了吗？
答案当然是：不可以。
如果这样就上线了，你会发现，有无数个坑在等着你跳。测试工作有一个很有趣的点：如果按照正常思维测出来的问题，都不是问题。意思就是一般测试环境发现不了的bug，都是不按照正常流程测试的bug。所以后面，给大家分享几个重构测试的注意点：1）如果是开发语言变更的代码重构，对于接口而言，出入参的特殊值处理（以出参为主）。例如：出参0.0和0，string类型的空值：null和””等，这都是需要引起重视的，需要和调用方确认使用方法。2）如果开发代码中使用到缓存redis，则需要关注重构前后的redis的key值以及读和写的处理逻辑是否一致。
在环境双跑的情况下，对于redis的key和读写逻辑如果做不到统一，很容易出现写数据之后查不到正确的值的问题。
3）在重构代码上线后，大部分都会选择重构前后的代码在线上环境双跑一段时间，这样可以保持产品稳定切换，所以在双跑的情况下，测试环境尽量模拟线上环境，通过域名转发，如果没有这种测试环境，则需要指定两个环境交叉读写等测试用例
4）在重构代码上线后，还需要长时间观察稳定性，如数据库连接，网络连接等是否报错率会增加，以及是否有优化空间。总之，代码重构测试不仅仅考虑的是基本功能的测试，还需要关注性能以及缓存，环境双跑等一系列的测试内容，这是我们这次的一些踩坑经验分享。
拿菜刀的黑猫警长