网瘾少年,野路子学的测试,擅长服务端

  • 如果想要在这种公司创造价值获得成就感,你可以转型产品经理,去拉齐需求,可以和老板、客户直接交互。
    如果想继续做测试,建议跳槽,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 这个确实有

网瘾少年,野路子学的测试,擅长服务端