Jmeter 有一个 webdriver 采样器。我们必须编写脚本。我们有用 opkey 编写的脚本，opkey 是一个基于 selenium 的工具。我们能不能把两者结合起来。这样我们就不必在 jmeter 中编写脚本了。
【问题讨论】：
标签： selenium-webdriver jmeter performance-testing jmeter-plugins
不熟悉 opkey，但 Selenium 对于任何负载测试超出非常微不足道的负载都是一个坏主意：
Selenium 从未用于大规模性能测试。 Selenium 及其更新的 avatar webdriver，为每个用户启动一个浏览器引擎，然后重放其中的所有用户交互。这对于功能测试非常有用，因为您在真实的浏览器引擎中执行客户端代码 - 但同时这对于性能测试来说是个非常坏的消息。浏览器实例是资源密集型的，扩展变得困难且昂贵。
即使使用像 Selenium Grid 这样的东西，实际上也是为了通过并行运行来缩短测试执行时间，但实际上并不是为了生成任何类型的负载。他们在their FAQ 的最顶部这么说。
这不仅仅是规模，当您的负载驱动程序本身资源非常密集时，应用的负载就会变得不一致。如果您发现性能下降，很可能是您的负载驱动程序是瓶颈，而不是被测应用程序。
话虽如此，您绝对可以使用 JMeter Sampler 或 Se Grid 或其他东西来驱动您的性能测试，只要您的并行用户规模在 10 多个。再次引用 Grid FAQ：
例如，要模拟 200 个并发用户，您需要 200 个并发浏览器以及基于 Selenium Grid 的负载测试框架。即使您在 Linux 上使用 Firefox（因此是最有效的设置），您也可能需要至少 10 台机器来产生这种负载。当 JMeter/Grinder/httperf 可以在一台机器上生成相同类型的负载时，这真是太疯狂了。
请注意，当他们说 JMeter 时，他们指的是 HTTP 采样器或更简单、更高效的采样器之一 - 因为即使是 webdriver sampler documentation 也这么说：
JMeter 允许创建多个线程，每个线程负责在服务器上创建负载。但是，对于 Web 驱动程序用例，读者应该谨慎对待他们将创建的线程数量，因为每个线程都会有一个与之关联的浏览器实例。每个浏览器都会消耗大量资源，并且应该限制读者应该创建多少个浏览器。
然后继续推荐使用最大值（比处理器内核数少 1 个）——对于大多数非弹性设置来说，这是一个非常小的数字。
【讨论】：