虽然我也很同意 “测试用例推荐直接用代码来映射”，但是这不光是对测试要求高，对团队要求也很高了，我们这种小公司连收拢接口都做不到 当然我们的业务也复杂不到测试用例维护不动的地步

这跟压测 redis 没得关系，瓶颈在 redis 要么是连接数配的不够要么内存不够，这俩排除了就只用去关注业务逻辑

你是有具体业务场景还是闲的无聊压 redis

ui 和接口没打通我觉得没多大价值

面试应该是你主动引导面试官聊你熟悉的东西

也就 tm 测试天天思考自己存在的价值。。。
不过质疑自己存在的价值是件好事，说明拿比干的多，哈哈

啊，区块链、物联网、云服务平台这不都是技术突破塑造出来的新业务吗。。。

有个东西叫做 jenkins，复制粘贴配置就完事了

区分开接口测试和接口自动化测试，接口测试可以左移，接口自动化测试右移
接口测试目的之一是为了提前了解后端实现逻辑设计测试用例，看不懂代码的话说实话没太大必要浪费时间做。。
接口文档要是研发花一周时间设计的，测出来不一样你可以叼他，要是他加班 2 小时写出来的你可以去叼他试试看撒

定发版时间都是有根据的撒，看具体啥原因能不能优化。一般搞到夜里发版就是因为会导致停服务，那让运维去做滚动更新，研发做代码兼容，就不用每个版本都搞到夜里发了。要么就是质量烂，只敢夜里发版然后验证，那就得一起努力提高质量了。或者就是老板拍脑袋决定的，上面两点做好了就可以去拍他脑袋了。。。