我目前正在编写一个JMeter插件来测试修复程序,以便在我们的Web应用程序负载很重时才会出现这种错误。
作为允许编写负载/压力测试以测试Web应用程序的特定部分的一般解决方案,我想到添加一个简单的restful Web服务来调用测试。这样做的主要原因是绕过浏览器,因为我们对此测试感兴趣的是业务逻辑和数据库访问层(传统内联SQL)。
这是值得花时间和精力还是可以使用JMeter来测试需要身份验证并严重使用Javascript和Ajax的复杂Web应用程序。
修改
这些测试的目标是测试业务逻辑和数据访问层如何处理重负载情况,以确保没有错误或并发问题。这是一个遗留的jsp Web应用程序(即在90年代中期编写),主要是内联sql,正在被移动到DAL层。
答案 0 :(得分:2)
通过为负载测试公开特殊API,您可以获得多项好处:
现在剩下的就是估算创建这样一个API的工作量,以及这些好处是否值得。
答案 1 :(得分:1)
直接进入业务逻辑的麻烦在于,您永远无法确定在表示层中没有出现问题,这会给您的服务器带来额外负担。并且单独测试业务逻辑可能意味着丢失可能的性能问题(例如,如果很多HTTP会话中有很多对象,那么您的服务器可能会将大部分时间花在垃圾收集器上,因为堆太低了),所以我建议创建一个复杂的测试计划,其中包含对服务器的所有调用。
实现这一目标的最简单方法是使用JMeter的HTTP代理,启动浏览器,让HTTP代理为您记录测试计划。
有关如何开始使用代理的信息,请参阅Basic JMeter Proxy Step By Step。
这将记录从浏览器到服务器的所有调用(你对javascript本身不感兴趣,因为这在浏览器上发生,所以不会影响服务器负载,尽管AJAX调用会)。
HTTP代理创建的测试计划将硬编码所有值,因此您可能必须通过它来识别每次调用时哪些值不同(例如,如果您有一个返回新ID的创建选项,后续请求需要使用服务器返回的ID。
要获取这些值,您可以将Regular Expression Extractors添加到您的请求中,并分配一个变量名称,然后可以在后续请求中将其重新用作请求参数。通过请求参数并确定哪些需要替换为需要从以前的页面解析的值可能有点乏味,但并不是那么难。
例如,如果您的页面在返回HTML中包含recordId
<input type="hidden" name="recordId" value="abcqwer123" />
需要在下一个请求中使用,您可以使用以下正则表达式来提取它:
name="recordId"\s+value="([a-z0-9]+)"
要记住的另一件事是确保您使用各种测试数据(例如,如果您模拟了许多用户登录,您需要确保不是每个测试都使用相同的userId运行,如缓存可能意味着数据库查找等繁重的操作只能在您第一次运行时完成。为了简化使用多个帐户,您可以使用CSV Data Set Config将值列表加载到变量中,然后随着每次迭代而变化
我的最后建议是考虑在Distributed Mode中运行JMeter。这是您在许多远程客户端上启动Jmeter-server的地方,然后所有远程客户端都执行相同的测试。这可以确保测试客户端自身通过没有足够的CPU核心或网络带宽来创建瓶颈,从而创建大量的同时请求。
答案 2 :(得分:0)
如果您有JUnit测试,您可以使用JUnit Sampler并重用数据访问和业务层的现有测试,而不是编写REST服务并通过JMeter调用它。