现阶段 AI 取代人工不现实，我们这有一个部门是 AI 员工，但是只能起到辅助作用。 AI 部门没办法从需求到落地直接搞定，需要人工去拆解功能点，理顺业务，然后发给 AI 员工，由他们输出测试用例、执行计划啥的。输出之后的文档也需要人工二次评审，AI 员工只是取代了最不需要思考的重复性工作。

祝大佬得偿所愿

管理没那么简单吧，好的管理人员应该会让下面的人觉得佩服。
我自己就佩服我的直属领导，他的双商很高，相同的场景，酒桌上我说不出他那么好的话。
他也教会了我一些东西，不仅是技术上的。
他也勇敢表露自己不熟悉的技术方向，放手交给下面去做，不会瞎指挥。
我们部门创造了公司内 3 年离职率最低的记录
如果我以后面临你的选择的话，我会直接去问现在的领导取经，所以你也可以找你认为最佩服的领导，看看他的意见。

哇，好爽的待遇

确实好用

已经抓了 3 天帕鲁了，缝合的是真好玩 =。=

蹲一下

好的，感谢

我司有干到快退休的，还是有 “老人 ” 的

第二个图，500 线程的场景，对应的吞吐量和响应时间波动比之前的场景大，个人拙见可以看看是不是 GC 导致

我也想说

我不管，反正白嫖了 6 个月会员，我选择性遗忘这个事故

这种存在大量历史数据的项目恰好接触过，处理方法是：
1、一轮测试做空库测试，或者开发库进行测试【校验功能和新增数据的业务连贯性】。
2、二轮测试迁移数据测试，用你们政数局提供一个历史迁移库做测试，并且让开发把迁移脚本给你们【测试历史数据能不能兼容现在的业务】并对所有数据 BUG 的修改脚本留下记录。
3、最后上线阶段，开发迁移最新一版本数据的时候校验所有迁移脚本是否遗漏，二轮数据测试的脚本是否被同步。

简单业务这样做比较快，复杂的金融类业务还是前端更快。对这种系统来说，为了系统稳定， UI 几年都不会迭代一次，成本很低。

你只做了两个对比 禁用 or 不禁用，其实还有一个删除 3.调试取样器。如果还是复现你的问题，那就是你自己脚本有问题 。理论上调试取样器不会对结果有影响

嗯嗯 ，还有硬件配置。感谢

是啊，但是项目现场因为客户或者其他商务原因，总有改动，我们是远程连现场的，而且不是一个部门，沟通麻烦。所以才会想提测上规范他们。

1、通勤时间太长了，很影响生活质量
2、传统行业里面做 IT 缺点很明显，就是楼主提到的那些开发过程很不规范，做起来很恼火；但是也有优势，就是你把这个系统的业务逻辑吃透了，就可以活到退休，不用太担心 35 岁危机

如果要模拟真实场景，更推荐 LR，locust 好像不能在同一个虚拟用户下像浏览器一样同时发多个请求

强 学习了

看公司目前最需要什么专项测试，先掌握一项

个人感觉 “PPT 文化” 不会违反敏捷，挺多时候 PPT 能让人快速了解一个项目或者产品，反而比一堆干文档来的快；只要 ppt 简洁精炼就行。

没有接触过游戏测试，插眼等大佬

很全面的资料了！
个人感觉渗透和入侵的关键区别是，签一份渗透授权书，只要有这个了，破坏性测试也是 ok 的。
但是授权书里面要阐述和后果和影响，同时跟被测项目的经理做确认。