Loadrunner MAPI Protocol

The comments made here about the Loadrunner MAPI protocol are applicable for Loadrunner version 8.1. MAPI is Loadrunner’s Microsoft Exchange protocol.

I had reasonably straight forward objectives for a test I was preparing. Ramp up a few hundred users who would simulate use of Microsoft Exchange, i.e. users who were logging on, sending and receiving emails

I expected that Loadrunner would work with Outlook much like Loadrunner works with Internet Explorer. Loadrunner can simulate Internet Explorer with multiple users and sessions all working independently. Whilst working with the MAPI protocol I discovered that Loadrunner struggles to interact with Outlook. Some of the problems encountered were:


1) Not all of the statements worked. While they did not cause any problems, they just did not do what they were supposed to do. For instance:

The following statement should return a message ID, which it didn’t.

msgid = mapi_get_property_sz_ex(&mapi, "Message ID");

The following statement deleted a mail, but would not delete another email unless the logon statement was reissued on a fresh iteration:

mapi_delete_mail_ex(&mapi,"NextMail", "Show=all", LAST);

2) While the logon statement worked, it was not possible to logon a user to Outlook unless that user was logged onto the domain. Theoretically, the web_set_user will do this for you but it was not possible to introduce a web statement into the email script.

3) Configuring Outlook and permissions on the Injector machines was very much a trial and error process. Some handy hints:

Sessions can be run as local or global sessions. If running as a global session, the Loadrunner statements all finish with a suffix of _ex. The following settings are required: Define mapi as ‘MAPI mapi = 0;’

When using a global statement, stick ‘&mapi’ as the first parameter e.g.;mapi_logon_ex(&mapi, "Logon",

The logon statement is as follows:

mapi_logon_ex(&mapi, "Logon",

"ProfileName=Default Outlook Profile",

"ProfilePass=",

LAST);


To login a user, check the following settings:

The profile name can be found by; Right click Outlook; select properties; select show profiles. Funnily enough, the default Outlook profile is actually called ‘Default Outlook Profile’.

A mailbox for a user will be associated with an Outlook profile. This can be checked or amended by; Right click Outlook; select properties; highlight the profile and select properties; select email accounts; select view or change email accounts; select change / add / remove as appropriate.

In the logon statement above, password is not entered, mainly because it does not seem to be required.

More than one virtual user could be used per injector with this protocol, however, each virtual user per injector was accessing the same mailbox.It is worth increasing the mailboxes in size otherwise error messages will be returned if the mailbox fills up.

There is a setting in Exchange that detects if an automated program is running which may cause a popup message to be displayed. This will cause execution of the automation to stop. In fact, any popup will cause execution of the automation to stop.If anyone else has had a better experience with this protocol than I have, I would be very interested to hear about it.

You will find below a sample Loadrunner script that may help with your load testing project:

char * message;
char * msgid;
api;
int rc;
int i;
MAPI mapi = 0;
char msg_id;

Action()

{
// Get the Message identifier of current email message.

msgid = mapi_get_property_sz_ex(&mapi, "Message ID");

lr_output_message("the message id is %s", lr_eval_string("msgid"));
lr_start_transaction("P02S01_Logon");
mapi_logon_ex(&mapi, "Logon", "ProfileName=Default Outlook Profile", "ProfilePass=", LAST);
lr_end_transaction("P02S01_Logon", LR_AUTO);
lr_think_time(10);
lr_start_transaction("P02S02_Send");
mapi_send_mail_ex(&mapi,"SendMail",
"To={send}", //"To=Greg, David Marie",
"Subject=Test7 {GROUP}:{VUID} @ {DATE}",
"Body=Test Message! Please ignore.This is text inside the body of the email"
"111This is text inside the body of the email "
"111This is text inside the body of the email "
"111This is text inside the body of the email "
"111This is text inside the body of the email ",
"ATTACHMENTS", "File=C:\\readme.doc", "ENDITEM",
LAST);
lr_end_transaction("P02S02_Send", LR_AUTO);
lr_think_time(10);
lr_start_transaction("P02S03_Send");
mapi_send_mail_ex(&mapi,"SendMail",
"To={send}",
"Subject=Test8 {GROUP}:{VUID} @ {DATE}",
"Body=Test Message! Please ignore."
"222This is text inside the body of the email "
"222This is text inside the body of the email "
"111This is text inside the body of the email ",
"ATTACHMENTS", "File=C:\\readme.doc", "ENDITEM",
LAST);
lr_end_transaction("P02S03_Send", LR_AUTO);
msgid = mapi_get_property_sz_ex(&mapi, "Message ID");
lr_output_message("the message id is %s", lr_eval_string("msgid"));
lr_think_time(10);
lr_start_transaction("P02S04_Open_email");
mapi_read_next_mail_ex(&mapi,"NextMail",
"Show=all",
"Peek=false",
LAST);
lr_end_transaction("P02S04_Open_email", LR_AUTO);
/* lr_think_time(10);
lr_start_transaction("P02S05_Delete_email");
mapi_delete_mail_ex(&mapi,"NextMail",
"Show=all",
"Peek=false",
LAST);
lr_end_transaction("P02S05_Delete_email", LR_AUTO);
*/
for (i=0; i<(atoi(lr_eval_string("{randnum1}"))); i++)
{
lr_start_transaction("P02S04_Open_email");
rc = mapi_read_next_mail_ex(&mapi,"NextMail",
"Show=all",
"Peek=false",
LAST);
lr_end_transaction("P02S04_Open_email", LR_AUTO);
}
lr_think_time(10);
lr_start_transaction("P02S05_Delete_email");
mapi_delete_mail_ex(&mapi,"NextMail",
"Show=all",
"Peek=false",
LAST);
lr_end_transaction("P02S05_Delete_email", LR_AUTO);
return 0;

Difference Between Verification And Validation Explain It With Example?

Verification and Validation example is also given just below to this table.

Verification	Validation
1. Verification is a static practice of verifying documents, design, code and program.	1. Validation is a dynamic mechanism of validating and testing the actual product.
2. It does not involve executing the code.	2. It always involves executing the code.
3. It is human based checking of documents and files.	3. It is computer based execution of program.
4. Verification uses methods like inspections, reviews, walkthroughs, and Desk-checking etc.	4. Validation uses methods like black box (functional)  testing, gray box testing, and white box (structural) testing etc.
5. Verification is to check whether the software conforms to specifications.	5. Validation is to check whether software meets the customer expectations and requirements.
6. It can catch errors that validation cannot catch. It is low level exercise.	6. It can catch errors that verification cannot catch. It is High Level Exercise.
7. Target is requirements specification, application and software architecture, high level, complete design, and database design etc.	7. Target is actual product-a unit, a module, a bent of integrated modules, and effective final product.
8. Verification is done by QA team to ensure that the software is as per the specifications in the SRS document.	8. Validation is carried out with the involvement of testing team.
9. It generally comes first-done before validation.	9. It generally follows after verification.

Example of verification and validation are explained below:
Suppose we have the specifications related to the project than by checking that specifications without executing to see whether the specifications are upto the mark or not is what we have done in verification.

Similarly Validation of the software is done to make sure that the software always meets the requirements of the customer by executing the specifications of the project and product.

Note that the customer and end users are concerned in validation of the software.

It is also crucial to differentiate between end users, and customers. Considering example, if you are developing a library monitoring system, the librarian is the client and the person who issue the books, collect fines etc. are comes under the category of the end users.

Techniques or Methods of Verification and Validation

Methods of Verification

1. Walkthrough
2. Inspection
3. Review

Methods of Validation
1. Testing
2. End Users

1) Verification and Validation both are necessary and complementary.
2) Both of them provides its own sets of Error Filters.
3) Each of them has its own way of detect out the errors left in the software.

Lots of people use verification and validation interchangeably but both have different meanings.

Verification process describes whether the outputs are according to inputs or not, and Validation process describes whether the software is accepted by the user or not.

Issues when creating Loadrunner scripts with the Java protocol

When writing a Loadrunner script that interacts with MQ, Websphere or Weblogic, as a scripter, you need to use the Java protocol.

This is a bit of a nuisance for those of us who have become familiar with C programming language and can use it with our eyes shut. The question is often asked, why do I need to use Java? I want to use C. Java can take a long time to use and logically seems to work quite differently to C.

Well, the answer is a little obvious (but only when you know the answer!) In order to develop Automation for MQ, Weblogic or Websphere, you often need to use the same libraries that the developers have used. The developers have often written the application in Java, and the supporting object libraries are the Java versions for the middleware products MQ, Weblogic and Websphere.

In many cases, the Loadrunner automation is simulating a device which runs the Java application. This could be a desktop, laptop or a handheld terminal (HHT). The device contains a compiled version of the code. This code is executed on one of three circumstances:

• The device is switched on and the operating system is configured to execute at start up
• An input is received from the device such as barcode being scanned
• A message is received from a middleware application such as MQ, Websphere or Weblogic

When executing an automated test script with Vugen, Loadrunner always compiles the script first. With a Java script, this will create a compiled version of the application similar to that which in the real world is located on the desktop, laptop or a handheld terminal. The main difference between the Loadrunner script and the real application is that the Loadrunner script would normally be written to process a distinct business function, i.e. it would contain only a subset of the functionality of the real application.

In order to compile the application, the Loadrunner scripter needs to have access to the same common java files as the developer, the so called JAR files. The JAR files need to be accessible to Loadrunner when it compiles. This is done by entering the information into the runtime settings. By specifying the location of the classpath files in the runtime settings, you are telling Loadrunner where to find the Classpath files so that compilation will work.

While this seems straightforward, the way Loadrunner works with the compiler means that it detects the names of the Classpath files, but does not necessarily determine where they are.

To get around this we can change the path statement on the environment variables for the machine running Vugen. This also does not always work. What should work is to physically place the JAR files in the Loadrunner directory of program files and set the Classpath statements accordingly.

At this point your script will compile and any other errors after this are down to real coding issues.

How we will do Spike Testing and Explain it with example?

Spike Testing is a form of testing process in which an application is tested with unusual increment and decrements in the load. The system is unexpectedly loaded and unloaded. It is done to notice how actually the system reacts with unexpected rise and decline of users.

Example:

when you are always checking the result of your exam on JNTU site means site is suddenly loaded and unloaded and then the IT squad of JNTU check how the site reacts with unexpected increase and decrease of users than it is Spike testing.

Spike testing is mechanism of testing which means when in a web page frequent number of visitor access the page unexpectedly increases to maximum then obviously performance of the page breaks down. So the mechanism of testing a performance about web page due to unexpected sort of traffic on the page is always called as Spike testing.

Spike testing is usually done by unexpectedly increasing the number of loads generated by users by a very enormous amount and observing the dramatic behavior of the system.

The goal of spike testing is to regulate whether performance will deteriorate, the system will always fail, or it will be able to hold dramatic changes in load.

A spike is a keen rise in the density for a given variable, generally immediately followed by a decrease. This category of transient variation is often notice in the measurement of voltage or you can say current in circuits.

Spike testing is always used in load and performance testing. These tests are commonly based on real universe or projected workloads with focus on huge load/performance conditions.Spike testing is handling to check whether a system can handle dramatic changes in load. It is accomplish by spiking the no of users of an application and always produces an excellent way of verifying existing limitations in the current operational environment. spike testing is a type of performance testing.