想想很丰满，现实很骨感。
现实是工作流还在用 jira 禅道，从来没要求过工作留痕，公司一时兴起就要搞量化考核，最后商量出来个工时加 bug 数作为考核指标。你据理力争不能这么简单粗暴，老板就要问你了，你有什么方案怎么落地多久落地，平常怎么不积累数据（谁有意见就是谁的问题了）。最后老板拍板，搞这个的目的就是给大家上上压力别太松懈了，搞错了个别人受点委屈，但是每个人都会绷紧一根弦，本来就没什么绝对的公平，不服气就换人。
然后推广 2 个月，研发开始懂得自测了，开始自己找活优化系统了，测试提供详细的冒烟用例了，bug 提交也规范了。
人家就是为了搞事情搞得考核，而且越简单粗暴看似不靠谱，反而越好落地，而且短时间内能见效果。我也不知道怎么评价这个事情，只能说站在不同立场看待 kpi 考核能得到完全不同的答案

现实中貌似都是根据经验估算个大概时间，没什么好的量化的标准

这只是手段，核心是让开发联调自测，不自测 bug 当然多，就不准提测，那测试应该提供冒烟用例，冒烟用例不通过就打回，打回要发邮件让领导知道提测质量差，具体到那部分功能谁负责开发导致打回的。写那么多隔靴搔痒的东西都没人当回事。

学会控制台看接口、服务器看日志，然后看开发代码，坚持 2、3 年，等我们这批 35 岁的被裁了你就出头了

建议你叼他一顿，你在教我做事？

做项目复盘，搞 bug review，拉着研发经理对每个 bug 做代码 review，这一套下来是驴子是马都能现形

你是只工作了三年还是在这家公司工作三年，要是只工作三年有这么多想法还是挺厉害的。
想实现想法首先要得到领导支持，多聊一聊获得信任然后给他画饼。
然后就是给出你的流程设计先在领导那过了再开会讨论，尽可能得到大部分人支持。
再之后就是实施阶段，在流程节点处卡住，给出准入准出标准，口越窄的地方越好卡，比如上线就在运维那卡，不嫌麻烦就让领导审批了才能上线，想上线就要输出标准测试报告、发布计划、测试用例、开发设计、产品原型等等。
再然后就是检查执行情况最好和 okr 挂钩，定期复盘优化流程，经过一两个月磨合基本上团队就习惯了，流程一定要灵活契合团队

笑死，是不是自己缴税，你猜工资提现了有关部门找你不

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

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

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

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

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

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

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

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

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

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

给我看笑了，你们啥业务 7 个人都带不起，是给 7 个蜘蛛侠演示爬数据吗

你先梳理需要哪些表的数据，哪些字段是敏感字段，如何做脱敏，先做了调查出了报告再去找领导协商解决方案。想推一个东西要么有能力把他变成老板的需求，要么有能力全靠自己去实现

关于平台化考虑过使用 jupyter notebook 吗

20 年毕业怕锤子，你现在唯一需要的就是脸皮厚一点，其他的都不重要

你去把唐僧师徒除掉

都是从这个阶段过来的，只是我现在的看法是现在的研发其实和几个世纪前的纺织工人没区别，但是珍妮纺织机（AI）已经被发明出来了