此文已由作者王婷英授权网易云社区发布。

欢迎访问，了解更多网易技术产品运营经验。

缓存，看到这两个字，第一反应，最近怎么又要弄缓存的改造啊，这个测试好复杂，一不不留心就踩一个线上bug。实在头疼。一般对于这方面的测试，都不会掉以轻心。但还是会踩到雷。那么怎么做才可以又快又好完成这个任务呢？相信每个QA都会有自己的测试应对方案，来达到高质量的上线。

接下来进行分享下社区这边测试solo缓存迁移的测试方案，有不周到的地方大家多提建议，有更好的方案，也可以分享下，让我们能更快更好的应对这方面的测试工作。本次社区这边迁移solo的工程有comment、comment-compose、community-compose、contact-compose等核心工程。

案例一：contact-compose的solo迁移（改动不大，代码改动整体比较清晰）

图一：专辑的改动

上面这两张图都是对contact-compose工程里涉及到专辑的内容进行NKV变更为solo，大家可以看到这个的代码的改动基本是一对一的改动，改动的范围基本都知道。那么接下来我们需要怎么测试这个需求。

【测试流程】

第一步、我们看了开发开发代码改动不是很大，然后就可以自己按照开发修改的地方列定下回归的范围

第二步、梳理下这个工程哪些业务是用到了缓存。

第三步、可以再找开发对一下范围

第四步、就双方进行评估下回归范围，就可以解决掉了。

通过上面的步骤，我们不仅可以做到心中有数，还可以起到监督开发是否有遗漏的地方没有修改。

上面这个是NKV的缓存迁移为solo的缓存，但是我们测试中还存在NCR的缓存，那么接下来聊一下NCR缓存的迁移。

案例二：community-compose的solo迁移（改动多，复杂性高）

图三：代码简单的统计修改数

当我看到这个改动，瞬间人变得紧致起来了，零碎的看开发改的代码，看了两天，当时抱着这个肯定会出线上bug的心情在忐忑的测试。

图四：community-compose工程对应的solo业务key有18个

这个回归起来如果没有一周肯定是不行了，当时心里这么一想，压力很大，怎么办还有好多任务，这个也是卡在4月底上线。有点想加班加死的想法。于是，我先把代码都部署上，把开关都关闭的时候，花了两个小时验证了下社区的核心功能没有什么问题。然后我再把这18个Key全部都打开了，回归了下正常的情况没发现异常后，我开始灰度了。在我心灰灰的时候，就在想，这么高风险的任务，怎样才能更好的去避免线上不出问题？突然一个开发过来和我说，单测过不了了，怎么办？

此时很感谢这位开发，让我想到了可以不用靠一己之力来处理了。借助灰度方案来协助这个高危需求。可能有人以为我是准备拿到beta环境进行灰度，NO，NO。预估了下再近一周内community-compose不会有上线，及时有上线也都是走hotfix分支，于是我把代码合到了dev分支，在stable_dev进行灰度。

采用用stable_dev进行灰度原因如下：

1、stable_dev环境的调用方是非常的多

2、stable_dev环境是单测执行环境

基于上面这两点，stable_dev可以模拟多并发下写缓存和读缓存的操作。可以不用自己担心，只要关注下群里对应的环境反馈，保证工程能正常的运行。同时每天定时关注下stable_dev对应的solo相关的日志即可。

总结：

1、对于部分迁移solo缓存改动不大的工程，我们可以按照常规流程去测试

2、对于复杂性高、改动大的工程进行solo迁移，我们可以用类比的方式利用有限的资源去协助测试（如用stable_dev环境进行灰度）

网易云，0成本体验20+款云产品！ 

更多网易技术、产品、运营经验分享请。

相关文章：

【推荐】