点击关注“有赞coder”
获取更多技术干货哦~
作者:西部
部门:业务中台/测试开发
业务方应用接入BOS需要依赖于bos-sdk,应用集群在启动时通过bos-sdk将应用指定注解的组件进行收集,收集完成后保存在DB中,集群中的每一台机器在重启时,需要保证入库时只有一条请求的处理能够正确入库,以保证数据不会重复入库以及数据插入冲突的情况,为防止出现上述情况,项目中采用分布式锁,对此我们针对项目中分布式锁的逻辑,以及业务拿到锁的实现进行了CR,CR的最佳指导我们采用结构化方式进行,分别从背景了解、业务场景、逻辑分析、异常分析、编程规范、非功能分析、可测性分析这几个唯度进行CR。
3.3 锁流程处理:
c 逻辑分析:
场景遗漏:
d 非功能点分析
可测性分析:
可监控:
逻辑处理不合理:
try语句块的逻辑在此场景核心是关注DB操作的,不应在try语句块中加入其它逻辑调用,换句话理解,如果DB操作成功,第34行调用失败或调用异常,则会走catch,与try中关心场景本意不符。
c 代码写法规范:
异常分析:
d 非功能分析
可监控:
可测性:
性能无
经过结构化CR,我们可以从背景了解、业务场景、逻辑分析、异常分析、编程规范、非功能分析、可测性这几个唯度发现代码在实现过程中的问题,当然上述代码中不论是锁自身实现,还是业务拿到锁之后的实现结合具体的业务场景可能还有一些隐藏的问题待挖掘,但通过结构化的CR方式 ,我们可以提前将一些显见的问题类型提前识别出来,防止这些问题击穿不同阶段的测试,引发线上问题,关于业务中台BOS的介绍,可参考有赞coder公众号中相关文章"千亿级公司低代码平台的测试体系介绍"。
招募优秀的你加入?:
Vol.367