如果想要在这种公司创造价值获得成就感，你可以转型产品经理，去拉齐需求，可以和老板、客户直接交互。
如果想继续做测试，建议跳槽，30 岁 8K4 年工作经验的功能测试，试着往管理方向入手吧。
如果我是你这种情况的话，我会选择转岗转行，外面月薪过万的机会挺多。

描述很烂，和 pytest 无关，有个业务场景需要多个接口请求实现，先理清测试点，测某个接口的返回值就把需要依赖的接口写成前置数据。我建议你先把接口用例设计搞清楚再写脚本吧。。。一个接口一个 case 怎么得出的。。。

描述上看不出是短时间，看描述是小概率会触发到权重为 0 的场景，再经过一段时间才慢慢打到 100% 的

看完后，有个疑惑，为啥不做 SLB 的 cpu 的监控告警。。。CPU 使用率达到 100% 才导致服务不可用，优化改进也没看到监控的优化项。

除了中间件的问题，其他问的没啥问题，对中间件的理解最好结合他项目中接触过的中间件去问，直接这样问除了 redis 大部分人是没接触过这些中间件的，“接触过哪些中间件？” “XXX 的缓存淘汰机制？” “redis 与 kafka 有什么区别，性能比较？” 这样展开来问比较好，可以看看他了解的深度，有比较深的理解接触到其他中间件也能驾驭。

确实很浅显，你这个只是工具的使用。
最好结合实际项目去说，如何设计的性能测试方案，被测服务配置，工具使用，获取压测结果，结果分析，通过压测结果分析出哪些问题（cpu 使用率过高，oom，内存泄漏，sql 慢查询等），性能调优（sql 调优 小表驱动大表、索引查询、id 字段能使用整型就不用 string、避免使用> in not in 等语法，缓存机制，消息队列优化，淘汰机制优化等）。

还得看提 bug 单的元素，我这边完全不适用，一个 bug 得写几分钟，还得经过研发、小组长审批，确认是否单测逃逸 bug、该阶段发现是否正常、严重程度也有硬性要求等，工具实现出来也得手写挺多东西，看不出明显的提效

这个做出来不小，相关日志还得配合抓包但没法精确获取到出问题的接口，否则只是找前端 bug，大多数 bug 提交平台都有模板提交、复制 bug，重复性工作主要是这些。而且做出来只适用于 web 端，对于移动端、服务端测试没啥帮助。

我整理了下评论，大多数建议大同小异，基于构建数据痛点去写小工具，大数据量、请求数据多层转换或加密、多个业务接口请求造单个数据、复杂的命令、客户端/app 机制一键点击。

提升 kpi 这个确实有