很多处理逻辑是通过 PRD，交互这些了解不到的，如果需要提高测试用例的深度，还是需要参与技术评审，对代码逻辑有一定了解的。

造数据没必要通过业务接口去造，可以通过调用较底层的 service 造数据，一般都是可以将流程简化的。

等回长沙的时候，可以有幸找到年 30 的，我就满足了。
打算再在上海攒 2 年，想到五一广场附近搞一套~好像现在要一万大几千了？

我感觉能力只是一方面啊，感觉测试岗，能力越强可能回长沙越不好找，因为不到一定规模的公司，可能就没有这个需求~

长沙测试实际待遇咋样呀？在 BOSS 上看，20 以上的岗位几乎没有~

不用拘泥与什么语言，其实都是用来帮你解决问题的工具。
我自己是 Java、Python 双修，做一些平台的项目喜欢用 Java，因为可以用现有的脚手架项目，并且可以复用一些已有的逻辑，后期维护感觉也更方便。做一些小工具或者脚本用 Python，量级轻，成本低，见效快~

和项目经理的工作内容重合太多了。
文中的措施几乎都是针对测试广度的，要强化测试深度的能力，还是离不开技术。
我认为技术和业务并不该割裂开，相辅相成的~

你两个接口在不同的线程组里？
那你可以写个 beanshell，将提取器获取的变量赋值到环境变量里，应该就可以跨线程使用了

然后如果你取出来的 id 数量不确定的话，我记得有个变量是记录了你取出来了多少个数的，你可以用 debug 取样器看下，那个后缀怎么拼写我不记得了~

V 前面有双下划线的，在这回复，自动给我把下划线给过滤了~

可以的，使用V 这个函数，可以将变量名后面的序号进行参数化拼接，将序号设置为 1~ID 总数的随机数，这样你并发的时候，每次请求都是从 ID 列表中随机取一条,类似这样：${V(ID_${__Random(1,10,)})}
这样满足你的需求吗？

你用正则表达式取出来了列表中改的所有 id，我记得在变量名的后面加上"_"+"序号"，可以引用你提取出来的集合中的与序号对应的数值。
比如 ID_1，就是引用取出的 ID 中的第 1 个 (这个序号是从 0 还是从 1 开始计数的，不记得了，你可以搞个 debug 取样器，看下变量的序号，这样比较确定些)