 |
Creating a Lotus Workplace Messaging test scenario with Rational Suite TestStudio
by
Cynthia
Barber-Mingo
Level: Intermediate
Works with: Rational Suite TestStudio, Lotus Workplace Messaging
Updated: 09/22/2003
Related link:
More Performance Perspectives
|
|
In a recent technical article, we described our experience using Rational Suite TestStudio to analyze a customer's Domino Web application. In this article, we expand this theme further, discussing how we used TestStudio to create a workload test scenario for Lotus Workplace Messaging 1.0, our newest standards-based email solution that extends the reach of your messaging infrastructure. We discovered that Rational Suite TestStudio is an excellent tool for rapidly prototyping and testing Lotus Workplace Messaging (LWM).
This article begins with a description of how we captured the activities of a user working with the Lotus Workplace Messaging demo. We then conclude with a detailed description of the test scripts we created based on the user activity, complete with sample code. Included are some of the lessons we learned and best practices we followed while developing our workload. Our goal is to provide some guidance to others who may want to use TestStudio to perform a similar analysis in their own environments.
This article assumes that you're an experienced Notes/Domino administrator, ideally with some familiarity performing system analysis with tools, such as Server.Load, Rational, or another enterprise-level load and scalability tool. Programming experience will also be helpful, especially when reading the sample scripts we included to help developers build their workloads for load and scalability analysis.
Capturing the Lotus Workplace Messaging demo user activities
We used Rational Suite TestStudio V2003 to record simulated users working with the Workplace Messaging demo on Lotus Labs. This demo allows customers to try LWM by registering for a temporary, seven-day account. With this account, users can send mail and examine all LWM 1.0 features.
The typical sequence of user actions for the LWM demo includes:
- Registration
- Logging in
- Reading mail
- Sending a mail message
- Logging out
We used TestStudio to capture this user activity. TestStudio allowed us to record the actions and break them into multiple scripts while recording. For example, once the registration action was complete, a simple button click allowed us to save this portion of the script as "registration" and then continue recording. This "componentizing" feature of TestStudio can give you great flexibility, since you can later mix and match these component scripts into another suite. For instance, the registration component script could be used again in another scenario. This also helps with script maintenance, since the registration script is shared with all scenarios.
Creating the test scripts
After we confirmed the single user experience through the TestStudio direct playback feature, we began "generalizing" the code to simulate multiple users. However, we first had to take the following into account:
- Once executed, the state of the application may change, making subsequent applications invalid.
For example, in the registration script the Domino NSF field element for the registration form hard coded a Notes ID. To accommodate this, dynamic values that can be derived from responses in the application should be "parameterized" and substituted throughout the application. This is a powerful feature; it allows more code paths to be exercised in LWM because static caching of test activity doesn't dominate the test run.
- A direct playback produces the exact user/client information contained in the recording.
In a playback script, the user whose actions were recorded is often hard coded within the application. These direct references have to be changed and enhanced for the application to be used with multiple users. Again, we parameterized all user information used in the script. Then we used TestStudio's randomize features to distribute user selections where appropriate.
- Testing and validation logic was required.
Sometimes our server worked during the record session, but was unavailable during execution. Fortunately, return codes are sent back with many send/receive functions within a script. This allowed us to test for these within our script. We used the HTTP received variable _response to make sure the expected data was returned. Rational also provides functions for parsing and manipulating known form types to help testers look for expected values.
- System names and connection information is hard coded into the record application.
Both the externally recorded system data and the TestStudio connection definitions are derived from the system name recorded. Within the recorded data, parameters must be substituted to make sure the host, port, and server names can be changed smoothly. In addition, the variable names for the connections should be changed to descriptive names for external customers to use it. This must be done for all instances of the variable within the project, or playback will be broken.
To address these, we used several methods provided by TestStudio to make playback scripts more generic. The next sections explain how we modified the scripts to do this.
Application state change
In the sample registration script, we recorded an explicit Domino NSF internal Note ID value and saved it to a file (shown in bold in the following script). However, if this database or file name were to change, the recorded get function would fail to register users successfully:
lwmreg_lotus_com_10 = http_request ["XDERegi~2.029"] "lwmreg.lotus.com:80",
HTTP_CONN_DIRECT,
"GET "
"/wmreg.nsf/9d00a126271e22c38525699300664dd9/$Body/0.49A4?OpenElement&Fiel"
"dElemFormat="
+ http_url_encode(datapool_value(DP1, "FieldElemFormat"))+
" HTTP/1.1\r\n"
"Accept: */*\r\n"
"Referer: " + SgenURI_001 + "\r\n"
/* "Referer: http://lwmreg.lotus.com/wmreg.nsf/regform?Open" */
"Accept-Language: en-us\r\n"
"Accept-Encoding: gzip, deflate\r\n"
"User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)\r\n"
"Host: lwmreg.lotus.com\r\n"
"Connection: Keep-Alive\r\n"
"\r\n";
There are several solutions to this issue:
- If you record the functions modularly, you can simply re-record the function that has changed and replace the new script for that component in the suite.
- If you know the internal application text that has changed, you can substitute it.
- If this information is dynamic and will be modified regularly, consider making the value a variable.
See the section "Hard coded system information" later in this article for a sample snippet of parameter code.
Hard coded user fields
In our LWM demo sample code, TestStudio automatically parameterized the user name and password sample codes because the code detected a probable need to modify this value for generic use. These variables (shown in bold in the following script) were then automatically associated with a construct known as a DataPool. By manipulating the DataPool variable name contained at the end of the script, we made the script instantly modifiable to simulate another user:
lwm_lotus_com_3 = http_request ["XDELogi~4.001"] "lwm.lotus.com:443",
(HTTP_CONN_DIRECT | HTTP_CONN_SECURE_128),
"POST /mailapp/j_security_check HTTP/1.1\r\n"
"Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, applicat"
"ion/vnd.ms-powerpoint, application/vnd.ms-excel, application/msword, */"
"*\r\n"
"Referer: https://lwm.lotus.com/mailapp/loginError.jsp\r\n"
"Accept-Language: en-us\r\n"
"Content-Type: application/x-www-form-urlencoded\r\n"
"Accept-Encoding: gzip, deflate\r\n"
"User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)\r\n"
"Host: lwm.lotus.com\r\n"
"Content-Length: 55\r\n"
"Connection: Keep-Alive\r\n"
"Cache-Control: no-cache\r\n"
"Cookie: WASReqURL=https://lwm.lotus.com/mailapp/secure/initialize.jsp?s"
"cheme=http; JSESSIONID=0000NSFDVTVTX52FG0ZP5HMG4MQ:-1\r\n"
"\r\n"
"j_username="
+ http_url_encode(datapool_value(DP1, "j_username_1"))+
"&j_password="
+ http_url_encode(datapool_value(DP1, "j_password_1"))+
"&action="
+ http_url_encode(datapool_value(DP1, "action_1"))+
"";
set Server_connection = lwm_lotus_com_3;
....
....
DATAPOOL_CONFIG "XDELogin" OVERRIDE DP_NOWRAP DP_SEQUENTIAL DP_SHARED
{
EXCLUDE, "action_1", "string", "Log In";
EXCLUDE, "j_password_1", "string", "password"; //Change these values to Modify user specific information in tests.
EXCLUDE, "j_username_1", "string", "XDE Tester2";
EXCLUDE, "objname", "string", "theFldrs";
EXCLUDE, "tabId", "string", "tab_mail";
}
The DataPool section in the preceding code is automatically inserted into the recording for this application. See the Rational documentation for the range of options available for generating this information dynamically after an initial recording.
Call validation
Any values hard coded within the application have the potential of being modified. In TestStudio, the text from the HTTP return values are returned in an environment variable named _response. Applications can use this value in combination with the Rational VU user's language search commands (match) to make sure expected values are present.
In the following sample record extract, the recording has provided a comment to indicate that 100 percent of the 18,496 bytes should have been received by the application at that time. If an export/print of the _response variable does not yield the appropriate number of bytes, you can insert an exception/deviation notice into the log.
http_header_recv ["XDESend~6.002"] 200; /* OK */
http_nrecv ["XDESend~6.003"] 100 %% ; /* 18496 bytes */
{
SgenRes_012 = http_find_values("mailSaveSent", HTTP_FORM_DATA, 1);
CHECK_FIND_RESULT(SgenRes_012,"mailSaveSent","true")
}
In addition, the preceding code snippet shows the Rational VU recorder has inserted a request to search for a value of true in mailSaveSent from the HTTP form resident in memory. A combination of the function http_find_values and the macro CHECK_FIND_RESULTS allows the script to check for a specific value.
This feature is provided to testers along with a number of utilities to make managing HTTP application checks easier. The Rational header file VU.h and the companion documentation Rational Virtual User Programmer's Guide are good sources for information on the features and functions for data validation within a script.
Hard coded system information
The following code segment contains a sample of the recorded system information. All the parameters for the system lwm.lotus.com and port 80 represent values that should be changed for customer specific information and tests. These values should be moved to new parameters to make the test choices more mobile.
By default, the recording application names HTTP connection variables the same as the server where the application was initially recorded. You can perform a universal change of the connection variable names to more generic names to logically separate the test variable function from the initial recorded function. As long as the variable name is used consistently, the variable name can remain the same.
More challenging are the embedded references to the locations within the application. The bold text in the following code reference the server for both the connect request and the HTTP request get. To generalize this application, all instances must be modified to a variable. This requires a familiarity with HTTP to know which references throughout the recording relate to the explicit server or to port names and numbers.
lwm_lotus_com_7 = http_request ["XDESend~6.001"] "lwm.lotus.com:80",
HTTP_CONN_DIRECT,
"GET /mailapp/messageEdit.do?method="
+ http_url_encode(datapool_value(DP1, "method"))+
" HTTP/1.1\r\n"
"Accept: */*\r\n"
"Accept-Language: en-us\r\n"
"Accept-Encoding: gzip, deflate\r\n"
"User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)\r\n"
"Host: lwm.lotus.com\r\n"
"Connection: Keep-Alive\r\n"
"Cookie: JSESSIONID=0000NSFDVTVTX52FG0ZP5HMG4MQ:-1; LtpaToken=sc3Fj5vIco"
"6ToujtqviF/xN0MoNc/kcjKA8DUV1cDj+t2BF0AuoAUoYGjwb6r52FDIEPPwtItR82DmomK"
"CBJIAb/Y7xWGld9qX7249JWHFMUiWPOXVmfOKHzinAJnPzfPdAaSCQJxbXabQ/IP6sn0gS6"
"rOz9rc24EMailNuTVX38mJ8t+9IOrtdoJw1gG3m0kWOjRkOSQn+UPBDalLdlyM8Y7ZL/dKO"
"3nUU761s7eRQSh2D8FXO8fTPkhRGFXxWhg+FAFjJ8R3GpXnty8vhFPs8t3FOXeHglI5gESd"
"uqLfMMU5neGwdhGCYeLsQ36s6P\r\n"
"\r\n";
You can change the preceding code as follows to ensure correct system and host name parameters in a connect request:
#include <VU.h>
{
//cbm - Generalizing a little to test
string hostname, portnumber, sitename,connectname;
string name[];
hostname="w3.lotus.com";
portnumber="";
if ( portnumber =="" )
else
{connectname= hostname +":"+ portnumber;}
sitename="/";//"/knac"
set Think_avg = 0;
localhost = http_request ["Form Da~001"] connectname,
"GET " + sitename + " HTTP/1.1\r\n"
"Accept: */*\r\n"
"Accept-Language: en-us\r\n"
"Accept-Encoding: gzip, deflate\r\n"
"User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; YComp 5."
"0.8.6; .NET CLR 1.0.3705)\r\n"
"Host: " +hostname+"\r\n"
"Connection: Keep-Alive\r\n"
"\r\n";
Conclusion
Our completed Lotus Workplace Messaging 1.0 test scenario provides us with a defined user workload profile, one that we can share across teams. This allows us to repeat analysis at different times in the product development cycle. And for good measure, these workloads are applicable not only to LWM 1.0, but to future releases of LWM as well.
In this article, we shared techniques that you can use immediately for your own LWM load and scalability analysis. We described several requirements we faced in developing our workloads, and how we satisfied these requirements by making several modifications to our Lotus Workplace Messaging scripts. This provides a glimpse of what Rational Suite TestStudio can do to help you meet your own testing needs, offering another option to consider for Lotus application scalability analysis.
As you can see, Rational Suite TestStudio can help you rapidly create a test scenario by capturing the activities of a single user and generalizing these activities to simulate large numbers of virtual users. We hope our examples help you when using TestStudio scripts to perform application analysis testing at your own site. We encourage you to download the demo versions of Rational tools available from the Rational product page. Take them out for a test drive and see how they can work for you!
ABOUT THE AUTHOR
Cynthia Barber-Mingo is an Advisory Software Engineer specializing in scenario development for the Lotus Solutions Engineering Test group. Her current focus is on Rational test tools, Lotus Workplace, and Domino integration code strategies. She's also served in senior engineering positions in Unix, Domino, SNA, and PC programming integration for IBM, Lotus, and Digital. Cindi holds a BA in Computer Science from Columbia. |
 |