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 OR Request 1(Follow redirect = false, redirect automatically false) +Assert1 +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 regards deepak On Thu, Sep 28, 2017 at 10:24 AM, Gratzer, Steve < [email protected]> 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 > > ________________________________ > [https://www.aciworldwide.com/-/media/aci-footer]<http:// > www.aciworldwide.com> > 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. >
