面试的水很深，没有绝对公平和绝对不公平之说。看你的角度

不管你在发请求上玩什么花，目的无非就是一个，找到性能的临界点,并尝试在不同的场景上找临界点
所以还是回到本质，你要清楚你发请求的场景，模拟多种场景去设计发压用户数，发压的策略.
你怎么做其实都不影响，只是的符合你的场景设定而不是与实际业务不符，那测试就没有意义

业务场景决定你的脚本加载策略。先确定需求再来决定怎么设计脚本，抛开业务空谈是没有任何意义的

jmeter 插件里有很多针对线程组的插件，都可以了解下，根据情况选择即可，基本可以满足各种用户加载策略.

如果必须要依赖 ui 才叫业务,这叫点点点根本不是业务.
最多只是把很多点点点拼在一起就变成了业务.
真正的业务关注点从来不是界面怎么做
而是在业务层每一步要实现什么
最终会产生什么结果，是否如业务所预期的.

我以为什么断言的使用心得，这种超级简单百度一大堆 copy 的结果有必要放上来么。那么多选项，如何使用，使用中有什么坑这些恐怕你自己都不知道把。

建议帖子还是分下类把.

ip 过滤不就可以很大程度上防刷。
接口参数里一些隐私字段加密

先别急着下定论，凡事不要拿工具做借口，先从自己的环境，脚本，压测策略开始着手，再一步步排查是不是 jemter 版本的问题还是插件问题还是什么

单接口测试先保证，再谈集成测试.

用 maven 是不是会更好

参数化是什么意思你明白么。就比如你一个功能操作你要点 100 次，操作一样，只是每次数据不同，如果你手点你要怎么点。
参数化数据能完全执行到的前提还是要看你 线程组里怎么设的，不是设了参数化就能执行完.

当你并发次数小，而随机变量相对较大时，重复的概率比较小；
但当你并发次数很大时，而随机变量才 5 位，很大概率会重复。
随机变量最好设成 18 位，有 uuid+ 时间等等一些不容易重复的数据，这样才能尽可能的保证随机数不会重复

注意层级关系，网上的教程其实都多了一层，选择 eclipse 或者 ieda 的时候注意选项

两个概念不要混为一谈,一个是你发起请求的场景策略，一个是你脚本如何跑的策略

谁说不能，你不熟悉 jmeter 而已,早就可以再脚本命令中根据你需要调整并发数，好好的看看函数助手里面的函数.
还有 Lr 支持再运行中修改线程数；开始 jmeter 是不支持的，但是现在也支持了，只不过方法有点曲折，但比不支持好

http://commons.apache.org/proper/commons-jexl/changes-report.html

https://commons.apache.org/proper/commons-jexl/download_jexl.cgi

Jexl - Javascript Expression Language: Powerful context-based expression parser and evaluator

把响应里的每个字段存入变量或者是全局属性，写道 csv 文件不就好了；以后要读就直接读 csv 文件

从来不认为靠工具就能改变一切,工具从来都是辅助而不是主导
就像自动化刚出来那会，好像 qtp，所有的手工测试都能下岗。

1 业务是设计到整个公司的，测试没有理由也不需要为整个技术的失败背锅。
2 要想从根本解决这个问题，需求，开发，测试，运维全部都要配合，这从来就不是一个部门的事情。
3 只从测试层面解决不了根本问题，只能说部分解决:从业务点着手，那个业务最需要改进，从小处着手，从最迫切需要解决的着手,一点点的改动，改动多了就是大的改动.不要追求大而全，那是绝对不可能做到的。
4 如何做到提高效率，那就看需要改什么: 需求的分析、用例的编写和评审、用例的执行方法、提高测试用例的执行效率、多种手段多种方法提高测试的覆盖率等等，都是可改进的点

工具很多，录制方式也很多，selenium,blazemeter 自己都有插件。github 上还有 loadrunner 脚本转 jmx 的项目

你不会翻墙，那没有资料。国外都出过很多书甚至完整的视频
youtube 上都有教程

以前有 alm，只是不知道现在 alm 对开源工具的支持程度

这种根本都不叫坑，一个界面显示而已不影响 jmeter 的丝毫使用，看上去不好看而已。
jmeter 如果真正看过每个菜单，知道每个菜单下大概是什么东西，根本都不会问这种问题。
这就是 jmeter 跟本都不熟悉，看到一个问题，就想着问，不想着自己去看看可能是什么原因。
很多问题 jmeter 本身就有解决方案，只是看你懒不懒愿不愿意自己花功夫,而是等现成的