缓存测试分享篇:如何利用测试环境进行灰度测试缓存迁移solo
此文已由作者王婷英授权网易云社区发布。
欢迎访问网易云社区,了解更多网易技术产品运营经验。
缓存,看到这两个字,第一反应,最近怎么又要弄缓存的改造啊,这个测试好复杂,一不不留心就踩一个线上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+款云产品!
更多网易技术、产品、运营经验分享请点击。
相关文章:
【推荐】 移动端互动直播(入门篇)
【推荐】 考拉Android统一弹框