I am evaluating the Telerik Test Studio, and have found most of it to be easy to use with the exception of the load tests.
The problem I am having is with testing pages that are protected by a standard asp.net forms authentication system.
I have tried recording the load test steps using a fresh login (no pre-existing login cookie), Have tried recording with a remembered login cookie from a previous browser session. And have tried recording a load test by having the login form create a new persistent login cookie.
The result of all methods seem to be troublesome. Eventually all of the methods I have tried end up with the load testing of application pages resulting in a 302 response redirecting them to the login page.
It would seem that there are issues with the logon cookies during a load test.
So, my question is how can I reliably load test application pages which are protected by an asp.net forms authentication page?
Any help would be appreciated.
Thank you.
23 Answers, 1 is accepted
I believe there are different mehtods of protecting asp.net forms authentication pages. If it's using Windows Authentication, Test Studio currently is not compatible with this specific authentication method. It should work just fine with application based login forms which use cookies or query strings for user/session identification.
We are adding Windows Authentication compatibility in our R2 release. This is due out by the end of this week. My suggestion is to wait just a day or two, get R2 when it's publicly available and try once more. There are a LOT of bug fixes and a LOT of new features contained in this release.
Cody
the Telerik team
Vote now
I want to catch up with you and inform you that our R2 release went public on Thursday of last week. I encourage you to upgrade to this version and try again. To get this just download the current trial from our main page. The link has been replace with the 2012 R2 trial version of Test Studio.
All the best,Cody
the Telerik team
Vote now
I'm using the latest version of Test Studio (2012.2.920.0) and the problem is still there.
To debug the issue I actually set up Fiddler as a reverse proxy and now I'm looking at HTTP traffic generated by the load agents. Guess what... the cookies are ignored by the load agents. I mean, they re-use the recorded cookies, but not the ones that get issued in real time during the test. Effectively, you can't test an Asp.Net site as it will always give you a new cookie at first request in order to track your session. Unless you use that cookie, which load agents do not, your test is doomed.
There goes a bug report.
Regards.
This is very simple to test, you simply need to make a plain .Net website using the project template in Visual Studio. The load tests will fail even against that simple site if the recording for the test includes login and logout steps.
Needless to say, if you are using session cookies, entire load tests can be invalidated as multiple "virtual users" are all hitting the same server with the same session cookie and end up corrupting each other's state.
Unless you selected the cookie to be a dynamic target, then this would be the expected behavior. Our Load Test will only echo back exactly what was recorded except for the dynamic targets you select to act as variable substitutions.
Greetings,Cody
the Telerik team
Vote now
All it is showing is a bunch of hidden form variables and input controls.
What you describe sounds like a Test Studio bug. Could you either:
a) Point me to a public URL where I can reproduce this behavior (I may need logon credentials to reproduce the cookie problem)
b) Send me the Fiddler trace demonstrating this cookie setting problem? If you want to send the Fiddler trace confidentially, you can either open a new support ticket (which are always private) and attached it or email it to support@telerik.com and reference ticket 607945 so that email gets redirected to me.
Cody
the Telerik team
Vote now
I've actually raised a bug about this issue (Ticket # 616417). In that ticket I have my test video attached, which (among other things) demonstrates dynamic targets and Fiddler trace. Glendon is right, you cannot choose cookies in dynamic targets and thus disable their recording.
Regards.
Thank you for that information. I just found out (by talking to our developer) I was incorrect in my understanding how we handle cookies in our load tests and for that I apologize for giving out incorrect information. Our load test does not show cookies as a dynamic target. However it is supposed to handle them correctly at run time i.e. whatever is set by the web server is supposed to be recognized and returned back.
I also found out we did find and fix a couple of cookie handling bugs recently. If you haven't already done so, please upgrade to 2012.2.920 which is our official 2012 R2 version released on Sept. 20th.
I'll go and look at your support ticket now.
Cody
the Telerik team
Vote now
I am sorry you have run into this problem. This is a known issue we recently discovered and are actively investigating what is causing it. I will update you when our software developer assigned to this bug has more details what is going on.
Greetings,Cody
the Telerik team
Vote now
I would consider this a critical bug of the software, is there any way to add dynamic targets manually?
Thanks
Thomas Mittag
You definitely are not the only person that feels that way. Also we do consider this to be a VERY critical bug. We had a software developer working on this problem full time for the past 3 days and I have some very good news I can now pass along to everyone.
In our investigation we uncovered 2 bugs causing cookie tracking problems during the execution of a load test. We are testing the fixes for this now. We will have a new build that we'll make available in a day or two, as soon as we finish our QA verification.
Cody
the Telerik team
Test Studio Trainings
Thanks for the update.
We need a couple more days. Our QA testers uncovered a problem with the proposed fix. We're working on this new problem now.
Regards,Cody
the Telerik team
Test Studio Trainings
The new trial build containing our Load Test Cookie fix can be downloaded from here:
https://dl.dropbox.com/u/12886581/Telerik.TestStudio.2012.2.1207_Trial.msi
For anyone that already has a license and needs the purchased installer, contact me through support@telerik.com, reference ticket 607945 and it will get to me. I will then privately send you the link to that installer.
Cody
the Telerik team
Test Studio Trainings
I am glad to hear we are making progress. If, as part of your investigation, you think this is a Test Studio bug, I'll be glad to look at this with you via GoToMeeting. I'll stand by for an update from you.
Kind regards,Cody
the Telerik team
Test Studio Trainings
I removed the link to our 1207 build because we found and fixed an additional bug where a load test would cause faulted virtual users if the web server was configured to send compressed responses. The build containing both fixes can be downloaded from here:
https://dl.dropbox.com/u/12886581/Telerik.TestStudio.2012.2.1219_Trial.msi
Cody
the Telerik team
Test Studio Trainings
I am also having an issue with cookies and load testing. It appears that all of my users are using the same cookie values, instead of getting a new set of cookie values and since there are AJAX calls once the user is logged in and the AJAX calls are setting new cookie values, the load tests are throwing server errors. I am using the latest version of Test Studio, 2012.2.1420. Am I missing a setting?
Donnie
We have included a number of Load Test related bug fixes, including stale cookies, in our latest internal build, 2012.2.1527. I recommend you download it from your Telerik.com account by navigating to "Latest Internal Builds" after logging on to our website.
Cody
the Telerik team
Test Studio Trainings