Building a Performance Testing Framework

8/14/2019 Building a Performance Testing Framework

http://slidepdf.com/reader/full/building-a-performance-testing-framework 1/16

1

RadView Software How-to

Building a Performance Testing Framework

Development framew orks have been around for years, and have servedas a catalyst for a more efficient development process. Next comes thequestion of how to improve the efficiency of performance testing?

In this document w ill show how to build a testing framework thatimproves the overall cost-effectiveness of performance testing w ith

WebLOAD.

April 2007



2

Table of Contents

Overview..................................................................................................................... 3

The Need For A Framework................................................................................. 3

Load Testing Framework Architecture ............................................................ 5

Framework Based Testing .................................................................................... 7

The Complete Sample ........................................................................................... 9

Using WebLOAD To Build Your Testing Framework................................... 9

Building the System API Proxy Layer.......................................................... 9

Building The API Abstraction Layer............................................................ 10

How to Deploy the Framework in Your Testing Lab ................................ 11

Determining The Included File Location................................................... 12

Distributing the Files To The Load Generator Machines .................... 12

Change Management ........................................................................................... 12

Future Enhancements.......................................................................................... 13

Class browsing.................................................................................................... 13

Include files intellisense ................................................................................. 14

Multiple file editing ........................................................................................... 14

Appendix – Using Excel As A Data Source For Testing Parameters.. 14

Appendix – The CODE… ...................................................................................... 15

The Agenda.......................................................................................................... 15

The FrameworkSample-AbsAPI.js file ....................................................... 15

The FrameworkSample-ProxyAPI.js file ................................................... 15

The ExcelParamFunction.js File ................................................................... 16



3

Overview

Load testing is a potentially ambiguous term with many definitions. We at

RadView define load testing by its goals: To guarantee the performance,scalability and reliability of internet applications. As such, an enterprisechoosing our solutions for load testing shall find features that address

these needs.By “performance” we refer to testing

the responsetime of a givenrequest while the

system is underload. By

“scalability” werefer to testing the

system inresponse to

growingnumbers of requests. Finally, “reliability” is

about verifyingthat the

response remains correct even under load.

When our support professionals work with development teams at large

enterprises , they are often asked how to take load testing to the nextstep and lower the total cost of ownership (TCO) of the load testingprocess. This document covers our load testing framework architecture

and demonstrates how an enterprise can leverage such a framework toget faster and better results from its load testing team.

The Need For A Framework

Development frameworks have been around for years, as a means forstandardization and acceleration of the development process. The same

reasoning applies to testing frameworks. Yet, in the past, manyenterprises questioned its cost effectiveness as they questioned the need

for test automation at all.

While test automation of functional testing can be substituted by manualtesting, load testing is always done with automated tools or not done at

all. The question of how to make load testing cost effective is still validand this document will show how a load testing framework can be a

key element in justifying its cost.

Load testing architecture divides the system into three parts. First, the

client GUI application, usually implemented as a browser applicationusing static HTML or a rich internet application such as Ajax applications.



4

Second, is the internet protocol available to access the system under

test, usually HTTP/HTTPS but may also include multimedia protocols suchas RTP/RTSP or “Web 2.0” protocols such as SOAP/XML or RSS over HTTP.Third and last is the system under test (SUT) which is the subject of our

load testing effort.

This leads to an important distinction we have to make between functional

testing and load testing. While both the client and the Server are testedtogether in functional testing, each of these components is testedseparately during load testing. Adding the client side load into the

equation would skew the results because the client processing depends onthe client machine (CPU & Memory) which is not simulated using thevirtual client load testing model1.

Figure 1 - Load testing architecture

System under test

Internet protocols

SystemAPI

Client GUIapplication

System API callsusing internet

protocols

SUT processing

The system API is a new layer that must be mentioned, which is now

easier to describe in the context of the growing adoption of serviceoriented architecture (SOA). In the SOA world the system API are the set

of services offered by different sub systems and consumed by the clientapplication, usually in the form of web services. System APIs are of coursenot limited to the implementation of SOA web services. Any reasonablystable system has some form of separation between the GUI and the

business logic, so the business logic functions can be accessed via a stableSystem API.

Since API’s are considered more stable than the trendy GUI applicationconsuming them, a method of load testing which is not affected by the

ever changing GUI application would create significant cost savings.

This is where the LOAD testing framework comes into play. It enablesrepeatedly building new load test agendas without recording a new script,

eliminating the additional work that may have been caused by changes tothe UI. The Load Testing Framework avoids dependence on the UI bydirectly calling the pre-defined system APIs, like any other callable object

within your JavaScript code. The agenda accesses an external resource to

1 A lot has been said on the need for client side load testing with regard to the growing use of

client side code like Ajax technology, but still the argument for separating it from the server load

testing

is

still

valid

and

if

we

consider

all

the

new

mash‐

up

application

created

by

consuming

different services into a “bigger” application, the need for separate service testing becomes even

clearer.



5

get the parameters for each of the calls. A detailed explanation of the

framework architecture is provided in the next section.

We will show how the framework can also be resilient to changes in the

APIs themselves, acknowledging that backend systems are also prone to

change, albeit less often. A detailed description of how the frameworkhandles such changes is listed below, minimizing the effect on the

investment that was made in writing the test code itself.

Load Testing Framework Architecture

WebLOAD includes all the required elements for building a custom testingframework and is built using a layered architecture approach. In this

section you will read about the different components comprising theframework. Some are provided as part of WebLOAD support for theenterprise, others are developed by the load testing team as an enterprise

specific framework, while the rest are testing agendas developed fordifferent load testing cycles. The following diagram presents the differentlayers of such a framework; a detailed description for each part isprovided below.

WebLOAD IDE framework

System under test

Parameterization support

Database TxtTxt

Parameterssupport layer

WebLOADagenda layer

API Abstractionlayer

Sys APIProxy layer

Sys call Cinterface

Sys call Binterface

Sys call Ainterface

Test AgendaDatabase

Txt

Txt

System API

System under test with System API – The system being tested is not

itself part of the framework, nor is anything that has to be installed on it.It is included as part of the diagram to show that the framework accesses

the listed, pre-defined system API.



6

System API proxy layer – This layer represent a static entry point for

each of the system API. This layer is built by the testing team as a one-time effort and serves as a basis for all future load testing of the systemand the services provided by that system. Each entry point includes only a

place holder for parameters, not the specific parameters for each call.

The following shows sample code for a System API proxy file:

/***** WLIDE - JavaScript - ID:4 *****/

// WebLoad IDE js file

function CelsiusToFahrenheit(Celsius) { /***** WLIDE - URL :

http://www.w3schools.com/webservices/tempconvert.asmx/CelsiusToFahrenheit - ID:2 *****/

wlHttp.Header["Referer"] ="http://www.w3schools.com/webservices/tempconvert.asmx?op=CelsiusToFahrenheit"

wlHttp.ContentType = "application/x-www-form-urlencoded"wlHttp.FormData["Celsius"] = CelsiuswlHttp.Post("http://www.w3schools.com/webservices/tempconvert.asmx/CelsiusTo

Fahrenheit")

return document.wlXmls[0].documentElement.firstChild.nodeValue }function FahrenheitToCelsius(Fahrenheit) { /***** WLIDE - URL :

http://www.w3schools.com/webservices/tempconvert.asmx/FahrenheitToCelsius - ID:3 *****/

wlHttp.Header["Referer"] ="http://www.w3schools.com/webservices/tempconvert.asmx?op=FahrenheitToCelsius"

wlHttp.ContentType = "application/x-www-form-urlencoded"wlHttp.FormData["Fahrenheit"] = FahrenheitwlHttp.Post("http://www.w3schools.com/webservices/tempconvert.asmx/Fahrenhe

itToCelsius")return document.wlXmls[0].documentElement.firstChild.nodeValue

}

API Abstraction layer – This layer serves two purposes. First, itprovides objects such as interfaces for the system services and makesthem easily accessible from the agenda. The second purpose is to provide

an abstraction layer for changes in the system API in case they happen. Amore detailed description on how to handle changes in the framework isgiven in section 0. Advanced users can use this layer to achieve better

modularity in their test code by wrapping little static system calls in thesame object or by using this object for state management between calls.Since this layer is implemented using JavaScript language, you can takeadvantage of the object oriented characteristics of the language such as

templates and others.

The following shows sample code for an API abstraction file:

/***** WLIDE - JavaScript - ID:2 *****/

IncludeFile("FrameworkSample-ProxyAPI.js", WLExecuteScript)

function TemperatureConvertor(){

this.ConvertCelsiusToFahrenheit = function (Celsius){

try {

return CelsiusToFahrenheit(Celsius) } catch (e){



7

warningMessage("CelsiusToFahrenheit returned an error")}

}this.ConvertFahrenheitToCelsius = function (Fahrenheit){

try {

return FahrenheitToCelsius(Fahrenheit)} catch (e){

warningMessage("FahrenheitToCelsius returned an error")}

}}

WebLOAD agenda layer – This is the load test agenda written by theload testing team. The agenda contains the test code itself, implementingthe test logic and setting the specific parameters for each function call.

The following shows sample code for an agenda file:

function InitAgenda(){

IncludeFile("FrameworkSample-AbsAPI.js",WLExecuteScript);}

var MyConvertorServices = new TemperatureConvertor ()Far = MyConvertorServices.ConvertCelsiusToFahrenheit(30)Cel = MyConvertorServices.ConvertFahrenheitToCelsius(86)

InfoMessage("30 degrees celsius are " + Far + " fahrenheit")InfoMessage("86 degrees fahrenheit are " + Cel + " celsius")

Parameterization support – The parameterization support layer is part

of the WebLOAD offering which allows the tester to read parameters fromdifferent data sources, including text files, excel files and databases. This

layer also allows the tester to write their own plug-ins for accessingparameters during runtime.

Framework Based Testing

This section provides a step by step guide for writing an agenda based on

an existing framework. I will use a sample web service available on the

web which provides temperature conversion services. Throughout thisdocument the sample uses Web Services as the protocol between the

client and the server. However, non formal API such as XML over Http orany messaging protocol can be used just the same.

We start by writing the agenda. Since we have the framework in place wedo not have to start with recording a session. Rather, we can go directlyto edit modeusing either JavaScript mode or visual edit mode. Let’s test

the ConvertCelsiusToFahrenheit service using parameters taken from a globalExcel input file. To do so we include the API abstraction layer file in ouragenda which makes the ConvertCelsiusToFahrenheit “known” to WebLOAD

and we declare the converter object:



8


IncludeFile("FrameworkSample-AbsAPI.js", WLExecuteScript);}

var MyConvertorServices = new TemperatureConvertor ()

Now we will call our ConvertCelsiusToFahrenheit service which takesthe Celsius argument as an input parameter and returns the result in

Fahrenheit. In this sample we are still using the hard coded parametervalue (“30”) as input. Later we will replace it with an external parametertaken from an Excel file.

Far = MyConvertorServices.ConvertCelsiusToFahrenheit(30)

InfoMessage("30 degrees celsius are " + Far + " fahrenheit")

Note that although the ConvertCelsiusToFahrenheit methodencapsulates an HTTP call to the server, the structure of the method, theHTTP setting and all other technical issues are hidden from the agenda

author.

As with any good load test we will want to replace the hard codedparameter (in our example, the Celsius argument) with a parameter taken

from an external source. Excel is an excellent source for storing testparameters, since it is tabular, easy to use and provides good connectivity

to enterprise data sources2. In the following example we created aJavaScript object which reads the lines from a given Excel file and stores

them in memory while providing an integrator function to get theparameter. To simplify the code, no error handling is implemented here3.

function ReadExcelParameters(FileFullPath){

var xlApp = new ActiveXObject("Excel.Application");var xlBook= xlApp.Workbooks.Open(FileFullPath);xlBook.worksheets("Sheet1").activate;var xlSheet = xlBook.activeSheet;

xlApp.visible = false;var x=0 ;for (x = 1;x<(xlSheet.UsedRange.Rows.Count+1);x++){

RowColData[x] = xlSheet.cells(x,1).value ;}xlBook.Close();xlApp.Quit();

}

2 Although you can read parameter from an external data source directly using your customer

COM/Java object or using excel external data source connection, using static data stored in excel

has several advantages, mainly it provides you with predictable results – meaning you can repeat

your

test

over

and

over

again

knowing

that

the

input

parameters

have

not

changed

and

not

affected your results. More about Excel as a parameter repository see the appendix. 3 Note that in order for this sample to run Excel has to installed on the load generator machine.



9

The Complete Sample

The following section lists the complete code of the sample for the abovescenario. This sample is based on the sample web service available athttp://www.w3schools.com/webservices/tempconvert.asmx.As you can see the test code writing in the agenda itself is very clean and

simple which makes it easy to maintain. This sample is comprised of oneagenda file (showed below) which references both theFrameworkSample-AbsAPI.js (which is the abstraction layer file) and

ExcelParamFunction.js, a helper file with the Excel parameterextraction object . This sample also assumes you have an Excel file onyour c:\RadView\Input drive named TempDegrees.xls with a list of the

10 parameters which are to be converted to Fahrenheit.


IncludeFile("FrameworkSample-AbsAPI.js")IncludeFile("ExcelParamFunction.js")

RowColData = new Array // To hold the temperature degrees values contained in

the Excel file }function InitClient(){

ReadExcelParameters("C:\\RadView\\Input\\TempDegrees.xls")}for (i=1;i<RowColData.length;i++){

TemperatureConvertor(RowColData[i])}

Using WebLOAD To Build Your Testing Framework

So far we have talked about the need for the framework and whatframework based testing looks like. In this section we will describe how to

build the enterprise testing framework using different WebLOAD features.

Building the System API Proxy Layer

The first step in this process is to build the system API proxy layer. This

could be done with a systematic approach where we build the whole layerat once or with an ad hoc approach where we build the different API calls

on demand. We start by listing the different services we want to build,usually from a given list supported by the back end system. We then

need a client application consuming these services. The client applicationcan be the actual client application used by the enterprise, if one exists, or

a test client application that was used by the service developers for unittesting their service. We use the WebLOAD recording feature on this clientapplication to record each of its services at a time in a separate agendafile. The result will be a recording of an HTTP call for a specific service

with specific parameters.

The following code shows a sample for such a recorded agenda:



10

/***** WLIDE - URL :

http://www.w3schools.com/webservices/tempconvert.asmx?op=CelsiusToFahrenheit - ID:2

*****/

//This is the main test page of our web services wlGlobals.GetFrames = falsewlHttp.Header["Referer"] =

"http://www.w3schools.com/webservices/tempconvert.asmx"wlHttp.FormData["op"] = "CelsiusToFahrenheit"wlHttp.Get("http://www.w3schools.com/webservices/tempconvert.asmx")

/***** WLIDE - Sleep - ID:3 *****/

Sleep(6149)

/***** WLIDE - URL :


//This is the call to one of the web serviceswlHttp.Header["Referer"] =

"http://www.w3schools.com/webservices/tempconvert.asmx?op=CelsiusToFahrenheit"

wlHttp.ContentType = "application/x-www-form-urlencoded"wlHttp.FormData["Celsius"] = "30" //Note the hard coded parameter in the

recording

wlHttp.Post("http://www.w3schools.com/webservices/tempconvert.asmx/CelsiusToFahrenheit")

We now have to turn this specific agenda into a framework agenda. Wedo this by wrapping the call with a function and extracting all the

parameters as arguments to that function. We also need to extract theresult from the response, which in our sample is the first element in theXML. Once we are done we should use the SAVE AS option in the filemenu to save this file in the include directory (see deployment issues later

in this document).

The following code shows the recorded agenda converted to a function:

function CelsiusToFahrenheit(Celsius) {

wlGlobals.GetFrames = falsewlHttp.Header["Referer"] =

"http://www.w3schools.com/webservices/tempconvert.asmx?op=CelsiusToFahrenheit"

wlHttp.ContentType = "application/x-www-form-urlencoded"wlHttp.FormData["Celsius"] = Celsius //Note the hard coded parameter replaced

with function param wlHttp.Post("http://www.w3schools.com/webservices/tempconvert.asmx/CelsiusTo

Fahrenheit") //Extract the results

return document.wlXmls[0].documentElement.firstChild.nodeValue }

We are done! We now have the first service implemented as a system API

proxy agenda. We now repeat this process for every service we want toimplement.

Building The API Abstraction Layer

We move on now to building the second layer, which is the API abstractionlayer. WebLOAD is based on open standards of web development and usesJavaScript as its main programming language. As an Object OrientedProgramming (OOP) language, JavaScript allows you to define your own

objects and make your own variable types.



11

All that’s required to build the API abstraction layer is to declare an object

with a method and to implement it in a separate agenda file.We will start by creating the object and defining its methods. Our objectdoes not need parameters during construction, so the creation of the

object is just a function with no parameters.

The following code shows the API abstraction layer object creation:

//=============================This is stored in a FrameworkSample-AbsAPI.js

/***API Abstraction layer ***/

IncludeFile("FrameworkSample-ProxyAPI.js", WLExecuteScript)

function TemperatureConvertor(){

this.ConvertCelsiusToFahrenheit = function (Celsius){

try {

return CelsiusToFahrenheit(Celsius)

} catch (e){warningMessage("CelsiusToFahrenheit returned an error")

}}

As noted before this is a very simplified sample of the abstraction layer.

In its place, you can implement any object oriented design practice, forexample storing the account number between calls as a property,reporting errors in a centralized manner etc.

How to Deploy the Framework in Your Testing LabOur testing framework makes use of WebLOAD’s ability to split the agendainto different files and include them in runtime. It is important tounderstand the search order WebLOAD uses when looking for a giveninclude file.



12

Determining The Included File Location

By default, Included Files should be in the “User Include Files” directoryspecified in the “File Locations” dialog box. You may redirect the defaultdirectory location if necessary by double clicking on the “User IncludeFiles” entry and specifying a new file location from the pop-up “Modify

Location” browse box. In general, WebLOAD searches for the included fileusing the following search precedence:

The load engine first looks for the included file in the default “UserInclude Files” directory. If the file is not there, the file request is

handed over to WebLOAD, which searches for the file using thefollowing search path order:

If a full path name has been hardcoded into the I n c l u d e Fi l e command, the system searches the specified location. If the file isnot found in an explicitly coded directory, the system returns an

error code of File Not Found and will not search in any other

locations.

Note: It is not recommended to hard-code a full path name, sincethe Agenda will then not be portable between different systems.This is especially important for networks that use both Linux and

Windows systems.

Assuming there is no hardcoded full path name in the Agenda code,the system looks for the file in the default “User Include Files”

directory.

If the file is not found, the system looks for the file in the currentworking directory, the directory from which WebLOAD was originally

executed.

Finally, if the file is still not found, the system searches for the filesequentially through all of the directories listed in the

Tools | Options | File Locations dialog box.

Distributing the Files To The Load Generator Machines

WebLOAD technology eliminates the need to copy the agenda or any of

the include files to the load generator machine. By placing yourframework include files in the user include file directory and specifyingthem as described in the previous section, WebLOAD automatically copies

these files to the target load generator machine.

Change Management

Change management is one of the key obstacles to test automation.Much effort was put into software engineering with object oriented designpatterns and practices all in an effort to minimize the cost of changes.

While changes in the code are somewhat acceptable, derived changes inthe test code are less acceptable. In this section we show how the

framework deals with minimizing the effect of changes and allows bettercontrol of the change process.



13

The first step in the process is to understand where changes happen. The

most common change in an internet application are changes in the GUIwhich typically result from a new design or UI fashion or due to thechanging needs of clients. By deploying a WebLOAD testing framework,

your testing remains unaffected by these types of changes, owing to the

protocol-based load testing architecture employed by WebLOAD. Sincethis architecture is not based on a user emulation level, the test script

does not have to change so long as the services called by the applicationare not changed. Also, since we deployed the testing framework, all of thesystem APIs are already available to us with no need to record them.

Here again, we see that UI changes do not affect us.

The second type of changes are changes in the services themselves.

Changes to these services are not common and with more and moreenterprises implementing Service Oriented Architecture (SOA), theseservices will become even more immutable. SOA is not another form of

object oriented design. It is an evolution of OOP and the three tierarchitecture, where one of the key factors for making an implementation asuccessful one are the immutable interfaces. The services interface mustbe as well defined and immutable as possible, otherwise external users

(outside of the scope of your monolithic application users) will not be ableto keep up-to-date with your interface changes. However, acknowledging

that services do sometime change, it is in our interest to control thechange process as much as possible. When service calls change by theaddition or removal of a parameter, the first part that is affected is thetransaction API calls layer. A new transaction has to be recorded for

the given changed service, which does not require a big effort. The

question now is how to handle all the scripts that depended on this APIcall? The framework helps us by using the JavaScript interface layer tocontrol the change. The object in this layer gets the call from the agendaand passes it to the underlying function API layer. Inside this object we

can add a default value for the missing parameter, or cut off the extraparameter passed from the agenda layer. Although the API has changed,we can keep our entire agenda repository running by changing only two

files. Obviously, a log call can be added in the JavaScript object to logeach agenda that uses the “old interface” in order to help the testing teamto gradually migrate the test code without breaking it first.

Future Enhancements

This document demonstrated how WebLOAD 8.0 can be used to build atesting framework, improving the process of your performance testingteam, thus reducing the overall TCO. In future versions of WebLOAD we

are considering a few new features which will improve the productivity of framework based testing even more. Here are some examples of areasunder development.

Class browsing

As noted in this document the framework makes heavy use of includefiles. A future version of WebLOAD may include some type of objectbrowser which will make navigation through the different framework

classes a much easier task.



14

Include files intellisense

As with other development environments, it would be very convenient if once we declare an object or function in our JavaScript library it wouldalso show up in our editor with intellisense support.

Multiple file editingAnother useful improvement for WebLOAD IDE would be the capability for

multiple file editing, eliminating the need to close and open each file overagain. Although this task is relevant mainly during the framework

development process, other testing tasks might benefit from it as well.

Appendix – Using Excel As A Data Source For Testing

Parameters

As noted before, Excel is a great tool for managing the test data for both

input parameters and test results. With Excel you can choose betweenusing constant test parameters for predictable regression tests, orrefreshing the datawhenever it is

updated by linkingan excel sheet to

an external datasource. The mainbenefit of linkingto external data is

that this data can

periodically beused in MicrosoftOffice Excelwithout repeatedlycopying the data,

which is anoperation that can be time-consuming. After linking to external data, you

can also automatically refresh (or update) your Excel workbooks from theoriginal data source whenever the data source is updated with newinformation. While this is good for testing with real data from existingsystems, it has an adverse effect on the predictability of the results since

changes in the input parameters affect the results of the test. Therefore, agood test run will include a combination of static regression tests with

some dynamic tests.

Another advantage of using Excel as a repository for the parameters is

test source code management. The Excel file can be easily saved with theagenda file in any source control system allowing better control for the QAteam over the test environment configuration. Most projects would like tofreeze their test cases along with their code freeze of every version,

allowing them to rollback both if needed. This process is much harder tomanage if you are using an external data source directly without storing

the data in a separate file.



15

Appendix – The CODE…Below is the code for all files used in this document

The Agendafunction InitAgenda()

{

IncludeFile("FrameworkSample-AbsAPI.js")IncludeFile("ExcelParamFunction.js")

RowColData = new Array // To hold the temperature degrees values contained in the Excel

file}

function InitClient()

{ReadExcelParameters("C:\\RadView\\Input\\TempDegrees.xls")

}

for (i=1;i<RowColData.length;i++){

TemperatureConvertor(RowColData[i])}

The FrameworkSample-AbsAPI.js fileIncludeFile("FrameworkSample-ProxyAPI.js", WLExecuteScript);

function TemperatureConvertor()

{this.ConvertCelsiusToFahrenheit = function (Celsius)

{

try {

return CelsiusToFahrenheit(Celsius);

} catch (e){

warningMessage("CelsiusToFahrenheit returned an error");

}}

this.ConvertFahrenheitToCelsius = function (Fahrenheit)

{try {

return FahrenheitToCelsius(Fahrenheit);

} catch (e){

warningMessage("FahrenheitToCelsius returned an error");

}}

}

The FrameworkSample-ProxyAPI.js filefunction CelsiusToFahrenheit(Celsius)

{ /***** WLIDE - URL :


wlHttp.Header["Referer"] ="http://www.w3schools.com/webservices/tempconvert.asmx?op=CelsiusToFahrenheit"

wlHttp.ContentType = "application/x-www-form-urlencoded"

wlHttp.FormData["Celsius"] = CelsiuswlHttp.Post("http://www.w3schools.com/webservices/tempconvert.asmx/CelsiusToFahrenhei

t")

return document.wlXmls[0].documentElement.firstChild.nodeValue}

function FahrenheitToCelsius(Fahrenheit)

{ /***** WLIDE - URL :

http://www.w3schools.com/webservices/tempconvert.asmx/FahrenheitToCelsius - ID:3 *****/

wlHttp.Header["Referer"] ="http://www.w3schools.com/webservices/tempconvert.asmx?op=FahrenheitToCelsius"

wlHttp.ContentType = "application/x-www-form-urlencoded"



wlHttp.FormData["Fahrenheit"] = Fahrenheit

wlHttp.Post("http://www.w3schools.com/webservices/tempconvert.asmx/FahrenheitToCelsius")

return document.wlXmls[0].documentElement.firstChild.nodeValue

}

The ExcelParamFunction.js Filefunction ReadExcelParameters(FileFullPath)

{

var xlApp = new ActiveXObject("Excel.Application");

var xlBook= xlApp.Workbooks.Open(FileFullPath);xlBook.worksheets("Sheet1").activate;

var xlSheet = xlBook.activeSheet;

xlApp.visible = false;var x=0 ;

for (x = 1;x<(xlSheet.UsedRange.Rows.Count+1);x++)

{RowColData[x] = xlSheet.cells(x,1).value ;

}

xlBook.Close();xlApp.Quit();

Contact Information:

North America RadView Software Inc.111 Deerw ood Road, Suite: 200

San Ramon, California 94583

Phone: 925-831-4808Fax: 925-831-4807Toll Free: 1-888-RadView

United Kingdom RadView Software (UK) Phone: +44-207-716-5840

Other Countries RadView Software Ltd.

14 Hamelacha Street Rosh Haayin 48091, Israel

Phone: +972-3-915-7060Fax: +972-3-915-7683

RadView corporate website: www.radview.com

WebLOAD community website: www.webload.org

Documents

Building a Performance Testing Framework