目前干测试也有 2 年多了，一直有个疑问说出来大家可以看看有没有更好的建议，每次用 jmeter 压测写脚本生成测试数据都是生成多个用户，模拟多个用户进行登录后进行操作，但是比如新建功能的接口那些新建的数据我并没有去生成这个合理吗？举个例子就相当于模拟 100 个用户，但是操作的流程和新建的数据都是一样的，这个合理吗？算不算是合格呢，各位大佬有什么建议吗？
理论上是合格的，数据的合理性是交给后台逻辑去判断的，但是你这个是压测，关注的是性能问题，只要并发上来了就行。既然你这个能跑通，说明后台没有对数据的唯一性进行校验，可能业务上就允许它重复，这个看自己的业务情况吧。
单接口压测，只要压单接口就行，前序流程你准备好数据就可以不需要加入到流程。
多场景压测更多是验证相似场景下，资源竞争类的风险排查，例如极端的死锁。
脱离业务的资源竞争，更多的还是看推流业务流量情况下的容量预测，不过在现代的运维环境下，更多的是看限流，降级，扩容等策略的生效情况了。
无所谓的吧，除非程序处理对输入敏感。
操作的流程和新建的数据都是一样的
那么如果是不一样的，对于后端的而言的压力是否有区别呢
理论上是不合理的, 毕竟压测就是要越贴近真实场景越好
鬼知道这些新建的数据在内存, 数据库, 中间件是怎么做生命周期管理的,万一哪个环节就是用名称或者名称的 md5 做 key 来更新呢?这样一个 insert 操作可能就变成了命中缓存.
实际上看给多少测试时间, 比如就给个 1 天, 连架构图都没时间分析, 那顶多在测试报告里面写一下由于时间有限, 使用的测试策略的局限性
相同的数据哐哐发, 早点下班就完事了
哈哈，哥们儿，你这问题问得特别好，绝对是个爱琢磨的人才！首先，我说明一下我跟你的干法是一样的，而且我相信大多数人也是这样干的，从业这几年基本上见到的人都是这样干的，有些人是因为时间安排紧张，有些人是单纯因为懒，还有一部分人是照猫画虎不知道对错的。
你说的这种情况，在某些特定场景下是可行的，但不够完善，可能会漏掉一些重要的性能问题，测试结果可能会失真。简单打个比方：这就好比你想测试一个超市在高峰期处理 100 个顾客的能力，结果这 100 个顾客进了超市，全挤在同一个货架前，拿一模一样的商品，排一队结账。这显然和真实情况差太远了，对吧？
这种情况比较适合模拟秒杀、抢券这种极端场景。
如果后端允许此类数据写入，那应该是没问题，新建表单的数据和用户可以通过参数化来解决，操作流程这个可以考虑通过分析生产数据，流量漏斗进行接口的流量分级
压测的核心还是看主要业务场景， 确保业务场景能够被准确覆盖的情况下，这种操作其实没什么问题。但是建议是在资源充沛的情况下，尽量还是仿真模拟。
弄个写数脚本，提前准备下数据丢到数据池，取得时候循环区或者少了自动补貌似也不麻烦吧
一般对于关键字段我会加个参数化，或者带个后缀，用计数器做一下自增 ID。
单人用同样的数据压测，有时候是不行的，查询操作还好不存在资源竞争，如果是增删改数据库会锁行或者表，你的压测出来的性能会比多人不同数据差，如果在这种情况下还达标那就不用管，如果不达标你可能就得多人不同数据来压测了，还有一般后端都有进行同一用户调用接口频率限制，或者缓存这些的也会影像性能。