这是个 BUG 吗？

若感觉有问题可以提 bug 呀

行百里者半九十，楼主加油！
希望早日看到楼主的完整解决方案。

如何更好地让不想用以及手指无力的死党好友去使用脑瓜崩辅助神器

首先呢，名字不同。

工作十年，这些是我在互联网公司的测试感悟
之前看了一些互联网公司的测试经验和技术介绍。最近又翻出来重新看了一遍，感触还是挺多的，可能也是由于工作时间长了后有了一些新的感悟。

jmeter 中调试取样器是否禁用影响正则表达式提取器？
答：否。二者相互独立。
请问正则表达式提取器是否必须配合调试取样器（Debug Sampler）来工作？
答：否。二者相互独立。

在 py 库里面看到了一个 postpy2 的 postman 兼容 Python 的库，但是这个库依然需要先将请求内容组装成一个 postman 的 collection 文件之后才能运行，而且运行的结果获取和效率还没有经过实验，这种方式可行吗？

必须可以啊，前提是你做的前端界面也没问题。这就相当于脱壳的 postman 换成你给做的壳。

所有的 bug 价值相当，你想听哪个？

请设想：单个用户的多次行为和多个用户的单次行为。
大象能承受多大的伤害呢？1 只狮子咬上 100 口，100 只狮子各咬 1 口。

不合适

敢想敢做！
加油，年轻人！

写的不错，给你个赞!
既然是高并发分布式性能测试，举例是不是该模拟 100 W 个用户并发？

这么说来，……

这么说来，你已经说对了

但是，……此时，……测轮胎，……比如，……验证码……

但是，你又说错了

结论：蛇没有脚

微信支付团队开发了一套独立的仿真测试系统。该系统根据验收用例金额的不同返回不同的响应报文，以满足商户正常功能测试、安全/异常测试及性能测试的需求。
具体可参考：https://www.likecs.com/show-40094.html

支付宝有一个供开发者测试使用的沙箱环境，会提供一个沙箱版的支付宝 app。
具体可参考：https://blog.csdn.net/weixin_42232931/article/details/114589925

"请求参数会根据你的选择动态变化"，虽不清楚你想表达的意思，但还是认为跟数据驱动无关。
你最好先解释下这句话，这种情况具体怎么影响到你做数据驱动了呢？

做数据驱动与"请求参数会根据你的选择动态变化"无关

所以说，这方面还是测试人员更专业

都是 C# 实现的。
4 个人 70% 时间做自动化，包括测试环境搭建，脚本实现，测试运行，结果分析，脚本维护，bug 提交和跟踪，还有 30% 时间做手工测试。我们的要求是自动化人员必须搭建环境和参与手工测试。

你这种写法没什么问题啊。
不同路径下文件上传，还可以写得更整齐 (无关优雅) 些。

files = {
    "field1": ("file", open(r"..\Folder1\file1.xlsx", "rb")),
    "field2": ("file", open(r"..\Folder2\file2.xlsx", "rb")),
    "field3": ("file", open(r"..\Folder3\file3.xlsx", "rb")),
    "field8": ("file", open(r"..\Folder8\file8.xlsx", "rb"))
}

注意：这里不要用循环语句。

测试负责验证并提交 bug，调查 bug 原因并修复由开发负责

要坚守阵地，绝不做叛徒！

长篇累牍

对于要不要查数据库这个问题，个人倾向认同的观点已经在 20 楼给出了引用。

敏捷的迭代节奏又要求快速测试反馈结果，这就使得传统的测试用例设计 - 编写 - 执行 - 维护的模式无法满足当下的测试需求。

呵～