Core Concepts of ACT | Performance Testing Microsoft .NET Web Applications

Core Concepts of ACT

The purpose of this section is to explain the core details related to ACT and provide a few tips and share experiences we have encountered to help minimize your learning curve.

Dynamic Tests

The dynamic test is a very powerful feature of ACT, which gives you the ability to record or manually create a list of HTTP requests that are sent to the Web server concurrently. Also, you can modify request header information such as referrer, user-agent, and query string. Dynamic test scripts can be created using Visual Basic Script (VBScript), Jscript, PERL, or any other COM-enabled scripting language. ACT only supports VBScript for recording a test script.

Concurrent Users and ACT Simultaneous Browser Connections

A concurrent connection to the Web application making a single request or a series of requests contained in a ACT test script is measured in simultaneous browser connections (SBCs). Other stress tools use terms such as stress threads" or virtual users," which are synonymous with the ACT SBC (load level). We are often asked How do SBCs relate to concurrent users?" Equating SBCs with concurrent users is difficult, because we do not always know the rate at which customers will be requesting pages from the Web application. Test scripts played back with no sleep time (the user s think time during transaction execution) often produce a faster rate of execution and greater load against the Web server than would be produced by the user walking through the application from a Web browser. Therefore, you may need to include random sleep times comparable to actual user think time in your scripts to slow the request arrival rate on the Web server, allowing you to more closely relate one SBC to one user connection and to better simulate real-world Web traffic arrival rates.

User Sleep Times

When creating test scripts, you will have the option of inserting user sleep times. These sleep times help simulate realistic usage of the application as they introduce user think times. For example, by inserting a 5-second sleep time in a script that simulates a user filling out an online form, you simulate a typical user s actions more accurately by taking into account the think time needed for the user to fill out the form. In ACT, Sleep is a method of the Test object. When an ACT test script is recorded, the following code will be inserted:

fEnableDelays = False If fEnableDelays = True then Test.Sleep (0)

By default, at the top of a recorded test script the fEnableDelays variable is set to false. To use a 5-second delay, or 5,000 milliseconds, you will need to change the following code in the ACT test script:

fEnableDelays = True If fEnableDelays = True then Test.Sleep (5000)

If needed, a random sleep function can be used by inserting the following snippet of code into a test script and then calling this function between each request:

Function RandomSleep() Dim lMinSleep, lMaxSleep, lSleep lMaxSleep = 5000 ' 5 seconds lMinSleep = 1000 ' 1 second ' create a random int within our range Call Randomize() lSleep = Int((lMaxSleep - lMinSleep + 1) * Rnd(1) + lMinSleep) Call Test.Sleep(lSleep) ' return the delay time RandomSleep = lSleep End Function

One negative aspect of sleep times is that they can decrease the amount of load a given client can produce. This could prevent you from identifying the true maximum concurrent usage. Also, if there is insufficient client capacity, you will have a much more difficult task detecting performance bottlenecks, because bottlenecks appear when maximum load is applied to the system. A test script with no sleep times simulates the transaction as if users had a pre-filled form which is being submitted immediately. Utilizing sleep times more accurately simulates production traffic and allows you to more precisely estimate concurrent usage numbers. When random sleep times are used, the argument can be made that one SBC equals one real-world user.

Users and Groups

Users are handled in ACT dynamically by providing a single unique user and password for each entry located in the default user group. There is a one-to-one relationship between SBCs and users. For example, if you set the SBC level to 25 you will need a minimum of 25 users to run the test. If your Web application uses anonymous authentication, by default ACT automatically generates the users required. If your Web application requires Basic or Windows NT LAN Manager (NTLM) authentication, you must have predefined usernames and passwords. ACT provides the ability to customize users either by manually generating user data (from the user interface) or by importing data from a separate input file. When executing your test, each SBC will have a unique username and password. This data is exposed in your script by using the ACT Test Object. The following code is an example of the Test.GetCurrentUser, which can be used to retrieve the username and password:

Dim oUser, sUserName, sPassword Set oUser = Test.GetCurrentUser sUserName = oUser.Name sPassword = oUser.Password

For most Web applications, allowing ACT to control your HTTP cookies is the optimal method for handling cookies. However, cookies can be set up initially when the test starts and handled automatically by ACT thereafter. For any request that includes an HTTP header named Cookie," ACT will show the exact response generated by the Web server, and it will be commented out by default when a test is recorded. The next line of code within your script will show the same request with the value (Automatic)." The ACT help file covers the syntax for reading and modifying cookie information in more detail.

Headers

Headers are handled automatically, but they can be changed in your test script to modify information such as referrer, user-agent, host, HTTP version, and other information passed in the header.

NOTE
If you create a test script that only contains the following syntax:

"Test.SendRequest("http://localhost/samples/browser.asp")"

ACT adds a set of default headers using "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)" as the user agent.

For example, if your application contains logic that is dependent on multiple user-agents (different Web Browsers), you can modify the HTTP header of a request to dynamically change and pass a mix of user-agents:

Dim sUserAgent, sArray(3), sSeed sArray(1) = "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" sArray(2) = "Mozilla/4.0(compatible;MSIE 4.0;Mac PowerPC)" sArray(3) = "Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001108 Netscape6/6.0" Randomize() sSeed = Int((3 * Rnd ) + 1) sUserAgent = sArray(mySeed)

Authentication and Encryption

ACT supports the most common authentication models and encryption methods that applications use during test execution. This includes Windows NT LAN Manager (NTLM) challenge-response Integrated Windows Authentication, Basic Authentication, Anonymous Access, Digest Authentication, and Passport Authentication. However, the ACT recorder does not record all of these technologies. There are workarounds for Integrated and Passport Authentication, which are discussed in their related sections. The following table provides a quick checklist of supported Authentication methods by ACT Test Recorder and Test Execution:

Table 3-1. Supported Authentication Methods
Authentication Method	Test Recorder	Test Execution
Anonymous Authentication	YES	YES
Basic	YES	YES
Integrated Windows	NO	YES
Passport	NO	YES
Digest	YES	YES

Integrated Windows Authentication

ACT supports the playback of Integrated Windows Authentication; however, you cannot record a Web application that has the Integrated Authentication option enabled within the IIS configuration. Some Web applications may still be functional with IIS set to accept Anonymous or Basic Authentication. For such Web applications, you can use the following workaround to record a test script with ACT:

Enable Basic Authentication in addition to Integrated Windows Authentication. This will enable ACT to record while other users browsing your Web application automatically use integrated authentication.
Record the ACT test script. You will be prompted to fill out the appropriate domain\username and password for your Web application.
Change the configuration for the Web application back to Integrated Windows Authentication.
Modify the ACT test script by commenting out the line of each request:
```
oHeaders.Add "Authorization", "Basic XXXXX"
```
Set up the ACT users with the proper domain\username and password that you want to simulate.
Execute the ACT test script.

Basic and Digest Authentication

ACT supports the recording and execution of your script with applications using both Basic and Digest Authentication. ACT will automatically include the following code in your script to specify the use of Basic or Digest Authentication:

Basic and Digest Authentication.cs

'Basic Authentication Code oHeaders.Add "Authorization", "Basic xxxxx=" 'Digest Authentication Code oHeaders.Add "Authorization", "Digest username="+chr(34)+"domain\username"+_ chr(34)+", realm="+chr(34)+"IBUYSPY"+chr(34)+", qop="+chr(34)+"auth"+_ chr(34)+", algorithm="+chr(34)+"MD5"+chr(34)+", uri="+chr(34)+_ "/storevbvs/"+chr(34)+", nonce="+chr(34)+"xxxxxxxx"+chr(34)+",_ nc=00000001, cnonce="+chr(34)+"xxxxxxx"+chr(34)+", response="_ +chr(34)+"xxxxxx"+chr(34)

Anonymous Authentication

The most common authentication method for Web applications is anonymous. ACT fully and automatically supports anonymous authentication for both the recording and the execution of your test script.

Passport Authentication

Microsoft .NET Passport is a suite of Web-based services that makes using the Internet and purchasing online easier and faster by providing users with single sign-in and fast purchasing capability. The single username or sign-in service is designed to provide a centralized, secure, and convenient service with which end users can complete transactions. Because Passport Web applications use SSL, the ACT Recorder cannot record when using this authentication scheme. You have to build the login portion of the ACT test script manually or remove Passport from the testing phase. Additionally, Passport applications may be implemented in a variety of ways, so test scripts can vary from application to application. When new builds of Passport launch, you might need to modify your test scripts accordingly. We provide a sample Passport Authentication test script written by the ACT Development Team on the companion CD included with this book.

Secure Sockets Layer (SSL)

ACT fully supports the execution of test scripts which request 40-bit or 128-bit SSL encrypted elements. However, recording an ACT test script with an SSL-enabled Web application is not supported, because ACT records through a proxy, and the data is already encrypted when it reaches the proxy. The workaround for this issue is to disable SSL during the record phase. Change the Test.CreateConnection method within your test script to use port 443 instead of port 80 and re-enable SSL on your Web server. The following code shows the syntax for the Test.CreateConnection method and a sample of the Test.CreateConnection method using port 80 and port 443:

Syntax	oConnect = Test.CreateConnection(strServer, lPort, bUseSSL)
Without SSL	oConnect = Test.CreateConnection("YourServerName", 80, False)
With SSL	oConnect = Test.CreateConnection("YourServerName", 443, True)

If it is not possible to disable SSL for your Web application, you can manually add the reference to encrypted pages of the site using the syntax above.

Using SOAP with ACT

SOAP is a slim XML-based protocol for information sharing in a decentralized distributed architecture. For more information on SOAP, visit http://msdn.microsoft.com/vstudio/. ACT does not include native support for SOAP requests, but a workaround is available that involves wrapping the SOAP body in concatenated quotes. The following code shows an example of this approach:

SOAP Workaround Code Sample

set con = Test.CreateConnection(YourServerName, 80, false) set req = Test.CreateRequest set headers = req.Headers req.Path = "/Logon.asmx" req.Verb = "POST" req.HTTPVersion = "HTTP/1.1" headers.RemoveAll headers.Add "Host", "(automatic)" headers.Add "SOAPAction", chr(QUOTE) & _ "http://YourServerName/LogonUser" & chr(QUOTE) headers.Add "Content-Type", "text/xml; charset=utf-8" headers.Add "Content-Length", "(automatic)" body = "<?xml version="& chr(QUOTE) & "1.0" & chr(QUOTE) & " encoding="_ & chr(QUOTE) & "utf-8" & chr(QUOTE) &"?>" body = body & "<soap:Envelope xmlns:xsi="&chr(QUOTE)&_ "http://www.w3.org/2001/XMLSchema-instance" &chr(QUOTE)& "_ xmlns:xsd=" &chr(QUOTE)& "http://www.w3.org/2001/XMLSchema" &chr(QUOTE)& "_ xmlns:soap=" &chr(QUOTE)& "http://schemas.xmlsoap.org/soap/envelope/"_ &chr(QUOTE)&">" body = body & "<soap:Header>" body = body & "<CorrelationHeader xmlns="&chr(QUOTE)&"http://YourServerName/"_ &chr(QUOTE)&">" body = body & "<Contents>string</Contents>" body = body & " </CorrelationHeader>" body = body & " </soap:Header>" body = body & " <soap:Body>" body = body & " <LogonUser xmlns="&chr(QUOTE)&"http://YourServerName/"&_ chr(QUOTE)&">" body = body & " <licenseeAccount>Microsoft</licenseeAccount>" body = body & " <userName>testact</userName>" body = body & " <userPassword>testact123</userPassword>" body = body & " </LogonUser>" body = body & " </soap:Body>" body = body & "</soap:Envelope>" req.Body = body set res = con.Send(req)

Parsing Viewstate within ACT

Viewstate is a feature of ASP.NET implemented to maintain state by using hidden form elements within your pages. ACT does not include native support for ASP.NET viewstate. However, the following example shows a workaround for this by parsing and manually encoding the viewstate:

Do Viewstate.cs

'Do VIEWSTATE parsing If InStr(oResponse.Body, "__VIEWSTATE") Then Pos1 = InStr(InStr(oResponse.Body, "__VIEWSTATE"),_ oResponse.Body, "value=") Pos2 = InStr(Pos1, oResponse.Body, ">") res = Mid(oResponse.Body, Pos1 + 7, Pos2 - Pos1 - 8) viewst = res End If ' Manually encode viewstates: ' Replace all occurrences of "+" with "%2B" viewst = Replace(viewst, "+", "%2B") ' Replace all occurrences of "=" with "%3D" viewst = Replace(viewst, "=", "%3D")

Manual encoding viewstates (or Post data in general) can be avoided by setting the following property: oRequest.EncodeBody = True

Protecting your Web Site from Inadvertent Stress Testing

ACT supports the Robots Exclusion Standard method used by developers of automated user-agents ("robots") and Web site administrators to determine areas of a Web application that are accessible to particular user-agents. To prevent ACT from sending requests to a Web server, you can create or edit a file named "robots.txt" in the server s root directory and add the following lines to the file:

# Stress Agent is the user-agent string ACT sends when identifying itself User-agent: Stress-Agent # / excludes ACT from all parts of the Web site Disallow: /

When a test is run against a Web site that is protected by a robots.txt file, ACT will appear to be running but no requests will be generated. However, the status pane will state that "Robots.txt denied access to Web server."

NOTE
There are scenarios where checking this exclusionary protocol will prevent you from running a test, such as when testing Passport. So, ACT allows you to disable this check in the project Properties dialog box. (Right-click the project name and choose Properties).