那一年漫天雪的博客

说起code review，大家都觉得应该是开发参与的，与测试无关。但是 如果测试同学合理的利用好code review ，也能带来事半功倍的效果！

故障之存储层缓存集群通常是单副本的，通过特定的分片算法，比如一致性哈希，来定位具体的缓存实例。部分缓存实例挂掉，一般来说带来的冲击并不大，基本也就是缓存命中率瞬间有个下降，然后逐步回升。但是如果缓存实例挂掉过多，甚至极端情况下全部挂掉的情况下，就会导致后端数据库的压力很大，出现延时变高，甚至出现雪崩现象。对于数据库压力太大导致雪崩，数据库再起来就又立刻被打爆，怎么都起不来的情况，最好的做法是在数据库层面就做好过载保护。在数据库不支持自我保护的情况下，一个替代的做法是通过 SRE 的手段来实现：一

自己总结的测试分析时，应该思考的一些点需求分析 确定需求范围、改动点，涉及到的功能， 功能交互分析 需求逻辑，业务流程图、时序图，各域之间的调用 测试点 2.1 接口测试 2.1.1确定接口变动，明确接口调用链路---新增接口，删除接口， 2.1.2 参数变动--入参变动，出参变动， 边界值分析、入参变动要考虑app新老版本的兼容性 2.1.3输入异常--包括入参为特殊字段类型、非法长度、边界值等 2....

一、字节1、框架选型，为什么选robotframework+appium(面试官觉得这两个框架太笨重了，)2、robotframework 是怎么实现关键字驱动的，原理3、appium 是如何支持多语言的，它运行的原理4、编码 给一个随机函数random,该函数只能随机生成0,1 用这个函数生成0-1000之间的数字，6、测试用例设计主要还是问了项目经验，简历上写的东西，...

最近这一次需求，自己负责的模块进度严重滞后，并且测试不完全，导致上线的时候心里没底分析一下原因：此次是新接的系统，并且此次需求的所有评审都漏掉了我，导致自己对需求理解不明确，并且开发改动点一直在变，1、应及时阅读需求文档，如果有问题，及时向产品/开发 提问-----做到厚脸皮2、提测后及时review开发代码，------切勿忘记，这样可以避免一些明显的问题，比如赋值对象错误等...