niekell

Still not fixed Sergei. I tried with the latest build which resolved our viewstate ASP.NET issue, but the WAPT GUI window will still not resize horizontally. Vertically I can change its height, but its width is fixed. Going to full-screen is the only way I can see all the window at once. That is still inconvenient, any idea when this might be fixed now as it has been 5 months already?!?! Best wishes, Paul. Senior Software Developer University of South Australia

Thanks Sergei. We downloaded the new version and it resolved the issue.

Hello WAPT folks, Just installed the latest and greatest WAPT Pro (3.1), ASPNETModule, and x64LoadEngine as follows. Item Version Comments ================= ================== =============================================== WAPT Pro 3.1 Build 30 July 2013 Used installer from WAPTPro3.1.zip x64 Load Agent 25 July 2013 Used installer from WAPTProx64LoadEngine.zip ASP.NET Module 19 March 2013 Used installer "waptaspnetmodule.exe" not zip Recorded a test as usual using the recorder in WAPT, which is how we've always done it. No issues in the recording. When I can to verify the recording it reports errors with the ViewState variable (made by the ASPNET Module) on all pages which are POSTs (GETs are fine as they don't have the ViewState variable). I've attached three images. 1) The WAPT Post Parameters for the first POST (Page 4) in my recorded Profile, 2) The WAPT screen from the Logs after a Verify Test when I click on the RED line named "Value of Variables", 3) The WAPT screen from the Logs after a Verify Test when I click on the GREEN line beginning "POST /Student/...". Previously the ASPNET Module has taken care of the parameterisation of the .NET ViewState and other parameters, after all that is its function... but now it is giving the error "[Error : cannot find the specified value in the server response]". Why? Best wishes, Paul.

Thanks Sergei, that will be good. I'm looking forward to the next build.

Hello WAPT folk, We recently updated to Win2008 R2 servers and WAPT Pro 3.0 (Dec 6 2012 Build). When in windowed mode (i.e. not in full screen mode) the WAPT application window can be resized vertically but not horizontally. It used to allow both width and height to be resized, but now it seems not to allow width to be changed at all (either bigger or smaller)! I would like the horizontal resize to work because I only have 1024 width available through RDC onto a single portrait mode 1050x1680 screen. Although full screen mode does size down, it is inconvenient to use all the time. Best wishes, Paul Dickson. (University of South Australia)

Hello WAPT Folk, We've been using WAPT for a few years now to load test some critical business applications and though there have been bumps in the road along the way we now have a working knowledge of how to configure the tests to evaluate performance and stress. However I would not say we are experts at using WAPT by any means. I want to check that our understanding of the interaction between Profiles, Iterations, Users, and Sessions, and then ask a question (actually request a new feature) related to that understanding. Profiles - a recorded set of web pages visited using either the inbuilt browser or an external one. Previously Profiles were composed of an Initial, Main, and Final part. These parts have been superseded with the advent of a Loop part, this allows sequences of web pages to be iterated through but does not limit the Profile to one part which has Iterations. Iterations - When there was a Main part, it allowed iterations of itself to occur which simulated a cycle of web page visits until the Iteration count was reached then the Final part was run. Now that there are Loop parts you can iterate multiple times in multiple Loops per Profile. Nice addition. Users - There are various meanings for this as they can be implemented various ways. I'm just going to cover the one we use as a standard, Basic Authentication against an Active Directory system. In the Properties of a Profile we check the Authentication checkbox and using the "Users and Passwords" button we load a text file with user information in it. The text file has a username then tabs to a password, this is a tab delimited text file with one set of "credentials" per line. Now on to how WAPT makes use of these Users. When a Profile starts its load test, lets say it does a Ramp-Up of 4 Users ever 3 seconds of 1000 Users and it takes a minute for a single run through of a recorded Profile to complete for a single User. From 0-60 seconds 160 Users end up beginning and executing their first run (Session 1) of their recorded Profile. Then when we get to 63 seconds into the test, the first three Users have finished their first run (Session 1) of their recorded Profile, so they begin Session 2 (their second run through the Profile, all parts, all loops, all over again). This means I would never get more than 160 Users active at one time, never have more than 160 Users logged in, and most critically for us never attempt login for Users 161-1000. This is a problem as there are times when we're not so much interested in performance or stress as we are robustness of the application we're testing. When using large User sets, some of our Users have data which is fetched during the execution of the Profile which causes errors and by running them through the WAPT Profile we can identify Users whose data is non-compliant with our standards and either code to handle it, or get the data corrected. This is an important component in making our web applications provide a robust User experience. Sessions - The number of times a specific User executes the recorded Profile. My question, really a feature request, is that WAPT allow some mechanism to limit the User's Sessions. MaxSessionCount? Perhaps near the "Break user session on errors" and "Wait [1] seconds after session failure" options in the Advanced section of the Properties of the Profile? Best wishes, Paul. Senior Software Developer University of South Australia

Hello, Why does WAPT record with one setting for "Active Scripting" and yet run with it turned off when inside a "Loop"? Here are my steps: 1) I recorded all my Profiles successfully via the IE integrated browser of WAPT Pro 2.5 with JavaScript ON. 2) I ran "Verify Test" without any "Loop" objects and it was 100% successful. WAPT reported everything was okay, and the database behind the test also showed all the data was being manipulated correctly. 3) I ran a "Verify Test" WITH a "Loop" around a group of pages in which data was being set then reset so as not to clash on the next iteration of the "Loop", BUT it always runs with JavaScript turned off! I have an ASP.NET AutoPostBack in the "Loop" and that is failing because it requires JS to be on. Why is JS off when inside a "Loop" but on outside it? That doesn't make any sense to me! Can someone please investigate it and fix it? Best wishes, Paul.

Hello, I am using WAPT Pro 2.5 on a Windows 2008 R2 server. Profiles are using random think time 3-20, Max connection speed, Loading Page Elements true, using cookies, using keep alive, breaking user session on error. Pages are under Basic Authentication and use SSL 2.0/3.0 and WAPT certificates. I recorded 10 Profiles without any errors occurring whatsoever during recording. When I attempt to "Verify Test" the recorded Profiles I get inconsistent results. Some Profiles run through to completion, others halt on error at random points with the message "SSL error. Some I/O error occurred. []". The Profiles are fundamentally the same, they merely have some data variations in them and navigate around the site in slightly different order, but all Profiles ~DO~ hit the same pages performing the same actions. The data variations record perfectly okay, so there is no problem with the data itself being run through the pages. Each "Verify Test" yields different results when it comes to which pages will throw the error. That indicates to me that the error is more likely with WAPT than with anything else. Why is WAPT throwing such random and uninformative errors? Best wishes, Paul.

Thanks Sergei. Ivan had me do the same thing. Yes it did resolve the problem. Best wishes, Paul.

Hello WAPT Folks, We've recently gone from WAPT to WAPT Pro and discovered that for our ASP.NET Applications WAPT Pro required the installation of the ASP.NET Module (at additional cost). So I downloaded the Module Trial and recorded a Profile to test. I verified it successfully, and then ran it with one user as a normal test. Then came the addition of load (in the form of another 799 Users) and the ASP.NET Module aborted the test because it was the trial. Fair enough, so we bought the full version of the Module and I uninstalled the Trial then installed the Full version of the ASP.NET Module. Here comes the problem, all the profiles recorded with the Trial ASP.NET Module now complain about there being a missing plugin. I check the server's installed programs and the ASP.NET Module is there. So what is going on? Is there some key which is inserted into the profiles during recording which is specific to the Trial version and the Full version is incapable of recognising it? I do not want to spend another 4hrs recording profiles! How do I get WAPT to recognise that the FULL VERSION of the ASP.NET Module should run anything the Trial version did?!?! Best wishes, Paul.

Seems like you'd record the 25 Profiles all in one Scenario, make sure the right user is assigned to each one (using the "Basic Authentication - Users and Passwords" option) in each Profile's properties page, and then just set a "Fixed User Load" of 25 Users for the Scenario and in the table area assign 1 user to run through each listed profile. -Paul Dickson _____________________________________________________ Paul Dickson BCIS (Computer and Information Science) Senior Software Developer: Student Information Systems Information Strategy and Technology Services University of South Australia (CRICOS Provider no 00121B) Office A2-05, A Building, Mawson Lakes Campus MAWSON LAKES South Australia, 5095 Email: paul.dickson@unisa.edu.au

Hello, While recording a profile for an ASP.NET 2.0 Web Application the Viewstate that is passed from one page to the next via hidden variables breaks sequence. Why? Is this a bug? I've attached the Scenario and Profile for the load test. I have removed the usernames and passwords. myEnrolment_RP_EnrolAddDrop3b.wps myEnrolment_RP_EnrolAddDrop3b.wpp The profile contains the addition of three courses to a student's data, then the removal (drop) of all three classes at once. Page 14 of the profile (adding the third course) is using VIEWSTATE9 (generated by Page 9 of the profile, which is the start of adding the second course) parameter rather than VIEWSTATE12 which was brought into Page 13 of the profile but not pushed out of that Page (13). I would have expected Page 13 to have a VIEWSTATE13 which was used by Page 14 much in the same way that Page 4 does. This is not consistant. Why? Best wishes, Paul Dickson. _____________________________________________________ Paul Dickson BCIS (Computer and Information Science) Senior Software Developer: Student Information Systems Information Strategy and Technology Services University of South Australia (CRICOS Provider no 00121B) Office A2-05, A Building, Mawson Lakes Campus MAWSON LAKES South Australia, 5095 Email: paul.dickson@unisa.edu.au

Hi Roshni, I'm pretty new to WAPT but I noticed this was happening to me when I tried to run two WAPT instances at once (I mean on the same server). They both seemed to run okay, but after running a test for both only the instance opened first would respond properly and terminate cleanly. The other instance just hanged there doing nothing, but still taking up memory. In the end the only way to get rid of it was to kill its process in task manager, as it was completely unresponsive. You might check to see if you have an abandoned process of WAPT in the background that didn't terminate properly, other than that it seems to be a bug in the software where it may not be handling resource allocation in an independent manner for each instance of the application. Sorry, thats all I can suggest from my own experiences (as limited as they are) with WAPT. Best wishes, Paul Dickson.