jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deepak Shetty <>
Subject Re: Need some help with HTTP responses and Assertions.
Date Thu, 28 Sep 2017 19:32:05 GMT
Im not sure I understand your issue exactly but hopefully this will clarify
a couple of things.

In JMeter , every request/response can be asserted against , but there are
a couple of flags that control whether you can do it on JMeter with some
implications for your test case.
The way I understand your issue is you are logging in , and then there are
a bunch of redirects that take you to the home page (or some page) and you
are writing asserts for this final page , but you'd rather write asserts
for the first post ?
The HTTP Request in JMeter has the Follow Redirects which controls whether
JMeter automatically follows redirects - If you do not want to this , then
uncheck it. Once you do that you can inspect /assert the response returned
. However your test script has to change to extract the URL being
redirected to and then a new sampler that actually makes a new request for
this URL.(You can use transaction controllers if you want both individual
times and grouped up times)

So effective you can either do
Request 1 (Follow Redirects = true, redirect automatically false)
   (Request 2,3,4,..n)
   Assert final

Request 1(Follow redirect = false, redirect automatically false)
+Regex extract , extract Location header into say url2)
+Assert 3xx response code

Request $url2 (follow redirects or not as required , if not then each
redirect needs its own request)

Note however in most systems there is really nothing to assert against in
Request 1 (other than status codes , if the system is issuing a redirect )
because there wont be a response - youll have to use a browser tool to
understand the request/response for your application


On Thu, Sep 28, 2017 at 10:24 AM, Gratzer, Steve <> wrote:

> Currently I have a jmeter script that does a login to a site.  The issue I
> am running into is that when the login process completes, it goes through
> some redirects and finally drops you at the landing page.  The landing page
> is what I am using assertions on.  Essentially, this works fine, but with
> one problem.  The landing page takes 20+ seconds to load.  So, when the
> script submits (POST) the password to proceed, jmeter takes 20+ seconds to
> load the response and then another 20+ seconds to reload the page with a
> GET sampler to do assertions on.
> This looks ugly from a monitoring standpoint as those two actions consume
> 40+ seconds to complete.
> At this point, I would like to do the assertions against the resulting
> return of the POST sampler instead of doing an additional GET sampler which
> adds another 20+ seconds to the script duration, but it doesn't seem to
> work that way.  I am assuming that the POST sampler is what the assertions
> are having an issue with.  They do not alert for missing content.
> So, I am wondering if there is something I am missing?  Is my
> understanding not correct, or am I trying to do something that isn't
> available?
> I do need to follow the redirects after submitting the password to check
> the final returned URL.  It may return a security validation page that the
> script has to address, so I can't turn that off.  Optimally, I would like
> to find a way that I can run the assertions on the final return results of
> a POST request.  This way I won't be getting the page automatically after
> the POST and then having to do a GET in order to perform the assertions.
> Jmeter version is 2.13 (not my choosing, that is what I have to use).
> Order of sequence:
>   1.  Establish session / Get login page
>   2.  POST username
>   3.  GET password page
>   4.  POST password
>   5.  Check for additional security URL
>   6.  GET landing page
> ________________________________
> []<http://
> This email message and any attachments may contain confidential,
> proprietary or non-public information. The information is intended solely
> for the designated recipient(s). If an addressing or transmission error has
> misdirected this email, please notify the sender immediately and destroy
> this email. Any review, dissemination, use or reliance upon this
> information by unintended recipients is prohibited. Any opinions expressed
> in this email are those of the author personally.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message