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

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

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

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

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

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

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

强 学习了

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

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