Web Performance 4.2 (beta) Migration Guide
This document provides details for users of Web Performance Load Tester version 4.1 who wish to upgrade to Web Performance Load Tester version 4.2. Load Tester 4.2 is more powerful and flexible than previous versions of Load Tester. For the most part, Load Tester 4.2 can automatically import and upgrade repositories that were written from previous versions. There are a small number of changes that existing users will want to be aware of in advance.
Once a repository has been opened in version 4.2, it will be impossible to open that repository in any older version of Load Tester. Load Tester will warn you before upgrading your repository. Especially during the 4.2 beta period, it is recommended to keep backups of all repositories before upgrading.
You can test all migration steps described in this document using the demo version of Load Tester 4.2.
NTLM support has been temporarily disabled.
NTLM is an authentication protocol that is common on some Windows intranets. NTLM is not supported in the 4.2 beta. Depending on demand, NTLM support may not be reinstated until 4.3. You will not be able to record new test cases or replay old test cases that use NTLM in 4.2. You will be warned immediately if you open an older test case that contains NTLM transactions.
This restriction applies only to sites that expose NTLM directly to the user. Some infrastructure, such as some Microsoft Sharepoint applications, may use NTLM to authenticate on the backend but use ordinary web page forms to authenticate the user. If this describes your system, then you don’t need NTLM support from Load Tester and it is possible to upgrade to Load Tester 4.2.
64-bit Load Tester uses 64-bit Internet Explorer
Load Tester is now available in 32-bit and 64-bit versions. For the most part these versions behave identically. Naturally, 64-bit Load Tester can support vastly larger repositories due to its increased memory limit, assuming the physical machine supports it.
Be aware that Load Tester is coupled with Internet Explorer in several places, and 64-bit Internet Explorer may have surprising behavior compared to 32-bit Internet Explorer. 64-bit Internet Explorer may not be able to load add-ons that otherwise work seamlessly on the same machine. For example, you might not be able to view PDF files in the content view (they would instead appear in a plain-text format that may or may not be gibberish, or in the worst case as a hex dump).
None of this will change the validity of your load test.
Our recommendation for the 4.2 release is to use the 32-bit version Load Tester unless you decide you need the flexibility offered by the 64-bit version.
Hostname redirections inside a Load Profile will no longer work (but there is a better way).
In previous versions of Load Tester it was possible, within the load configuration, to redirect all users in a specific test case to a different hostname. This technique was discouraged and rarely used even in version 4.1, and in version 4.2 has been entirely removed.
If you used the “mass edit” menu to change the hostname, then this warning does not apply to you and your test case will continue to work normally, although the mass edit menu itself has also been deprecated (see below).
It is still possible to redirect users to a different hostname, but this is now done in the Fields View, not the load configuration editor. Choose the “hostnames” customization in the Fields View and configure all Host:Port fields to point to the new hostname.
How to mass-edit fields and headers.
The Fields View and Headers View have changed significantly, and the “mass-edit” functions that were in Load Tester 4.1 have been subsumed by the new capabilities of those views. All of your existing work with these features will be naturally upgraded into the new Fields View, but you’ll want to familiarize yourself with the new interface. It is now possible to sort, filter, and multi-select the entire view and selectively mass-edit by any arbitrary criteria. For more information, see our article about the new Fields View.
The Application State Management Wizard has been streamlined.
In previous versions of Load Tester, the Application State Management (ASM) Wizard could be used to selectively disable (using “Extract Always”, “Extract Once”, “Never Extract”) the automatic configuration of certain fields. This interface no longer reflects the ASM’s actual operation and has been removed.
If you manually configure a field, the ASM will see this and will leave it alone — however, if you set a field back to it’s original value (either by using the “Recorded” datasource or by using the original or default value in a “Text Constant” data source) the ASM will see the field as unconfigured and try to reconfigure it.
The solution in this case is to use the global ASM ignore list, which resides under Window > Preferences > Web Performance > Configuration Wizards > Application State > Ignored Fields. You can set an ignore rule by either the name of the field or the value it might contain.
— Lane, engineer at Web Performance