 |
 |
 |
 |
HTTP/S Scripts
- What are Scripts?
- Understanding Scripts
- Planning Your Scripts
- The Core Functions of Script Modeler
- Script Modeler Interface
- Toolbars and Function Bars
- Script Pane
- Query Results Pane
- Output Pane
What are Scripts?
Scripts form the content of an HTTP/S performance Test using HTTP/S Load.
After you have planned a Test the next step is to develop its content by creating the Scripts you need. Launch Script Modeler from Commander to create and model Scripts, then incorporate them into your performance Tests.
Script Modeler records HTTP/S traffic during a Web session and creates a Script exactly as the browser issued its requests. When a Test that includes the Script is run, the Script is replayed exactly as the browser made the original requests. This means that the target Web Application Environment (WAE) receives the same number of concurrent, asynchronous connections and requests from each simulated browser user, or Virtual User, just as it would receive from real end users.
Scripts represent the recorded HTTP/S requests issued by a browser to a target WAE during a Web session. They are created by passing HTTP/S traffic through a proxy server, the Gateway, and replacing the original HTTP/S commands with SCL commands. The Gateway interfaces directly with the Script Modeler and uses Script Control Language (SCL), to represent HTTP/S recordings.
Using SCL to write Scripts gives you control over their content. It enables you to model them by introducing variables to modify the fixed values they record. In turn, this gives you control of the performance Tests that incorporate them and enables you to effectively test the Web activity you want with the load levels you require.
When you record a Web session a .HTP file and a .ALL file are produced. The .HTP file contains the HTTP/S browser requests issued during the Web session written in SCL. This file is the Script which is designed to be modeled and replayed as part of a Web performance Test. The .ALL file is directly related to the .HTP file and stores the WAE responses in several categories, including the DOM, which can be utilized to model the accompanying Script.
All Scripts are stored in the Repository from where they can be included by reference into multiple Tests.
See also:
Understanding Scripts
Successfully recording, modeling and incorporating Scripts into Tests requires an understanding of the components and concepts which are related to them in HTTP/S Load.
See also:
Cookies and Automatic Cookie Modeling
Tests
A Test is a set of user controlled definitions that specify which Scripts and Collectors are included and the parameters that apply when you run the Test. They also include the results that are recorded which can be monitored while they are being generated during a Test-run and displayed in graph and table format after the Test-run is complete.
Scripts and Collectors are the building blocks of a Test which can be incorporated by reference into many different Tests. Scripts determine the contents of a Test and Collectors define the data collection to be carried out during a Test-run. The Scripts and Collectors you add to a Test are organized in Task Groups. Select the Settings you want to apply to each Test Task Group to control how the Test is run and the level of load that is generated against the target WAE. Task Group settings include the number of Virtual Users, the Host computers used and the number of times a Script is replayed during a Test-run.
Develop your performance Tests by planning their structure and content, then create the Scripts and Collectors you need in order to simulate the type of activity you want to test. Scripts record HTTP/S activity during a Web session and Collectors control the type of data that is collected when a Test is run. Use Commander to manage and run your Tests along with the Scripts and Collectors they contain.
See also:
The Gateway
The Gateway is a component of OpenSTA which interfaces with Script Modeler to enable you to record HTTP/S traffic and create Scripts. It functions as a proxy server, residing between the client browser and the remote Web server hosting the WAE under test. When you begin a recording using Script Modeler the Gateway overrides some of your browser's internet connection settings, forcing the use of a proxy server, in this case the Gateway. The Gateway can then record the Web activity between browser and WAE and produce a Script, which is represented using SCL scripting language. The Script can then be modeled using the Script Modeler.
The Gateway records browser requests in a .HTP file, or Script, and WAE responses are stored in a .ALL file. The .ALL file contains HTML data which is directly related to the .HTP file content. It can be used to model the Script by manipulating information it contains including the DOM, the Document Object Model.
See also:
The Gateway and Script Creation
Scripts and SCL
HTTP/S Load uses a scripting language called Script Control Language (SCL), developed by CYRANO, to represent Scripts. SCL is used to control and represent the HTTP/S traffic they record.
Using SCL to write Scripts gives you the modeling capabilities you need to develop realistic performance Tests. You can model a Script or a sequence of Scripts, to simulate thousands of Virtual Users in order to generate the load you require against one or more target WAEs when you run a Test.
See also:
The Gateway and Script Creation
HTTP/S Scripts and Test-runs
Using HTTP/S Scripts to develop performance Tests has several advantages over client level or browser based replay techniques. HTTP/S traffic is the key information that is generated during a Web session. Capturing Web activity at this level enables you to record the activity of a variety of browser types across various platforms. Scripts can be modeled then referenced in Tests that simulate realistic conditions when they are run. After capturing and modeling Scripts you can replay them as part of a Test to exactly replicate the original browser commands. The HTTP/S requests are concurrently and asynchronously run on as many TCP connections as the original Web session, multiplied by the number of Virtual Users you select to run the Test.
Developing and executing HTTP/S based Tests is much less resource intensive than other techniques involving full browser emulation, which enables you to develop Tests that run a larger number of Virtual Users.
See also:
Virtual Users
Virtual Users are a key feature in OpenSTA.
A Virtual User is the simulation of a real life browser user that performs the Web activity you want during a Test-run. The activity of Virtual Users is controlled by recording and modeling the Scripts that represent the Web activity you want to Test. They are generated when a Script-based Task Group is executed during a Test-run and are used to produce the load levels you need against target WAEs.
The identity and activity of Virtual Users running a Test can be modified by modeling the Scripts they run to include variables that replace fixed values in the Scripts. For example, if a Script includes logon details they can be modeled to replace the original browser user's identity with a variable. You then have the ability to replay the Script as part of a Test which includes multiple Virtual Users each with their own unique identity.
Open a Test and select a Script-based Task Group to configure your Task Group, which includes your Virtual User settings. Specify the number of Virtual Users you need in order to generate the level of load required against the target WAEs when the Test is run.
See also:
DOM Addressing
The Document Object Model (DOM), is an application programming interface for HTML and XML documents. It defines the logical structure of documents and the way a document is accessed and manipulated. When a Script is being recorded the Web pages returned are saved in a .ALL file. During the replay of a Script as part of a Test the contents of a particular DOM signature or DOM object address, can be recovered dynamically. This enables modeling of the dynamic nature of some Web pages.
The term DOM addressing describes the ability to access and model specific and unique elements within the DOM or Web page, using Script Modeler. Address DOM elements to modify Scripts to improve the representation of the unique behavior of users during Test-run, such as the selection of different links within a Web page.
See also:
Cookies and Automatic Cookie Modeling
A cookie is a packet of information sent by a Web server to your browser when you connect to it, that is saved on your computer. Typically they contain user identification details such as name, password and other preferences. The next time you connect to the same WAE, the cookie is automatically retrieved from your computer. This allows the WAE to recall information you have already given, freeing you from the task of re-entering it. The WAE can then process the cookie information and customize the Web page it sends back to you.
Cookies form part of the HTTP/S traffic recorded in a Script if the WAE you are targeting issues them. When you use Script Modeler to record a Script, cookies are automatically modeled, which means that the cookie identity is copied into a variable that replaces its unique identity with a new variable definition. This is an essential requirement for the replay of a Script as part of a Test. A Script containing unmodeled cookies records a unique session identity that would be rejected by the WAE if it was replayed during a Test-run to represent one or more Virtual Users.
See also:
Automated Script Formatting Features
The Repository
The Repository is the storage area on your hard drive or networked computer. All the files that define a Test, including Scripts and Collectors, and the result files produced during Test-runs are stored here.
The contents and structure of the Repository are immediately visible through the Repository Window in Commander. It is located on the left-hand side of the Main Window and displays all the Scripts, Collectors and Tests that are stored there. You can work from the Repository Window to initiate the creation of new Scripts and to open existing Scripts.
See also:
Planning Your Scripts
Make sure you plan your Scripts before you begin recording them. Planning the creation of Scripts involves identifying which WAE functions you want to test, deciding who your clients are and how you expect them to use the Web services, and establishing the type of Test structure you want to develop.
Recording a sequence of Web activity in a Script is a straightforward process once you have planned the functionality you want to test. Making the behavior of the Virtual Users you generate during a Test-run more realistic can be achieved by modeling the Scripts.
The type of users you want to represent may be a consideration during the planning stage, depending on the nature of the WAE functions you are testing. Representing first time users or repeat users during a Test-run should influence the steps you take before recording the Scripts. If you want to simulate first time users it is important your Scripts are accurate, so make sure that you have cleared the browser memory cache before recording. This ensures that the WAE is stressed with a realistic load during the Test-run. Alternatively, if you are simulating repeat users, ensure the Script recording conditions support this requirement. Visit the WAE and conduct the activity you want to test before you record the Script so that the Web pages and their content are held in the memory cache and the Scripts reflect these circumstances.
Commander supports a versatile Test structure. Tests can include a single Script but a modular Test structure can be more efficient. If you create smaller Scripts that record specific client browser actions, such as logging on and entering a password, it is possible to reuse them in other Tests that involve accessing the same WAE. You can incorporate the same Scripts in any Test stored in the same Repository.
Also, it is easier to maintain a Test that represents browser activity with a structure that incorporates several smaller Scripts in a modular Test structure. A Test incorporating a single or a few large Scripts, takes much longer to update when there are changes to the WAEs functionality, than a modular Test structure comprising several smaller Scripts
So capturing the right activity in your Scripts is important in the development of a successful performance Test.
See also:
The Core Functions of Script Modeler
The Core Functions of Script Modeler
See also:
Launch Script Modeler
You can move directly into Script Modeler from Commander.
- In the Repository Window within Commander, double-click
Scripts, to expand the directory structure.
- Double-click on a Script icon
or
, within the tree structure.
See also:
Script Modeler Interface
Script Modeler supplies versatile Script creation and modeling functionality. Use the menu bar and right-click menu options to create and model Scripts.
After you create a Script or when you open one, the .HTP file is displayed in the Script Pane on the left-hand side of the main window. It is represented using SCL code which enables you to model it using the menu options or directly by keying in the SCL commands you need.
The Query Results Pane is used to display WAE responses. HTML information is recorded during the same Web session as the corresponding Script and is directly related to it, which enables additional modeling options.
The Script Modeler interface consists of four primary areas:
Script Modeler Interface Features
The main features of the Script Modeler interface are detailed below:
See also:
Toolbars and Function Bars
Script Modeler Toolbars include:
- Standard Toolbar: Use the functions provided here to open, create new and save Scripts, edit text, print, view full screen, search for text and display URL Details.
- Capture/Replay Toolbar: Use this toolbar to record, end a recording, replay and compile your Scripts.
- Variable Toolbar: Use these options to add and edit variable definitions.
- URL Address Bar: Displays the URL GET, POST and HEAD commands, contained in the current Script.
Script Modeler Function Bars include:
- Title Bar: Displays the name of the current Script.
- Menu Bar: Displays Script Modeler menu options. Click on a menu option or use the keyboard shortcuts to access and select the functions you need.
- Status Bar: Displays information about the current Script including the cursor position within the .HTP file displayed in the Script Pane.
See also:
Toolbar Display Options
Script Modeler includes three toolbars which are located below the Menu Bar in the main screen. A fourth toolbar, the URL Address Bar appears when you create a new Script or open an existing one.
You can change the position of the toolbars by clicking on the double bar on the left-hand side of the toolbar and dragging them to a new location. Either within the toolbar area or floated in the Main Window. You can also choose to display or hide the Standard Toolbar by using the View menu option.
See also:
Hide/Display the Standard Toolbar
Hide/Display the Standard Toolbar
Script Pane
When you record Web activity using Script Modeler a .HTP file and a .ALL file are produced. The .HTP file, or Script, is displayed in the Script Pane and represents the browser requests recorded during the Web session. It contains the HTTP/S data written in SCL that is designed to be modeled and incorporated into a Web performance Test.
Use the Script Pane to view and model the HTTP/S traffic recorded in your Scripts. The recorded HTTP/S traffic is represented using SCL which gives the recorded data structure and enables you to model the Script if required.
The HTTP/S data displayed in the Script Pane constitutes the Script which determines the behavior of your Virtual Users when replayed as part of a Test. The Script Pane is a window directly into the Web activity you simulate when you run a Test.
A Script records HTTP/S requests issued by a browser during a Web session. It is dynamically linked to the HTML information represented in the Query Results Pane which records the WAE responses, the Web pages that are returned, in a .ALL file.
See also:
Resize the Script Pane
- You can adjust the size of the Script Pane by clicking on any border it shares with another pane and dragging it to a new position.
Query Results Pane
The Query Results Pane displays HTML and other data relating to the current Script that is stored in a .ALL file. This file is created at the same time and is directly related to, the corresponding Script, which is saved as a .HTP file during the original Web session recording. Some of the HTML information it contains, including Structure, Document Object Model (DOM) and Server Header are dynamically linked to the Script, which enables additional modeling capabilities.
The Query Results Pane remains empty until you populate it by selecting a URL GET, POST and HEAD command from the current Script displayed in the Script Pane, and click
, the URL Details button. The HTML data stored in the .ALL file directly corresponds to the .HTP file. The .ALL file is never updated and only overwritten if the Script is rerecorded.
The data is organized into five categories represented by tabs at the bottom of the pane. Click on a tab to view the data corresponding to a selected URL command. The five categories are:
- The HTML tab presents a browser view. It displays the Web page that corresponds to the URL command you selected in the Script Pane.
- The Structure tab displays the structure the selected Web page, including links, frames, images and other components which make up the page.
- The DOM tab displays Document Object Model, information URL composition and structure of a Web page. It presents a more detailed structural display of the diverse elements that comprise a Web page.
- The Server Header tab displays the HTTP/S response header fields sent from a WAE to the browser. Including the date the HTTP/S information was recorded, the kind of connection used and which Web pages were contacted.
- The Client Header tab displays the HTTP/S request header fields sent by the browser to a WAE.
See also:
Display Query Results Pane Information
Display Query Results Pane Information
- In the Script Pane, use the scroll bars or the Find function to locate a URL command, or:
- Click an insertion point inside the URL command.
- Click
Resize the Query Results Pane
- Adjust the size of the Query Results Pane by clicking on any border it shares with another pane and dragging it to the new position.
Output Pane
The Output Pane is used to display results of Script compilation and to report the progress during the replay and compilation of a Script. This includes any errors and other status messages.
Output Pane information is organized into four categories which are represented by the Query Pane Tabs at the bottom of the pane.
Click on the tabs to view the information they contain. The categories are:
- Check: This tab displays compilation progress and results.
- Replay: Click
, in the Capture/Replay Toolbar to replay a Script. The replay progress is displayed here. Replay data is retained until you close the Script file. During this time you can view the replay data at any time by clicking on the Replay tab.
- Find In Files: Displays search results generated after using the Find In FIles button
, in the Standard Toolbar.
See also:
Resize the Output Pane
|
OpenSTA.org Mailing Lists Further enquiries Documentation feedback CYRANO.com |
| |
|
|
|
, to the right of the URL Address Bar text box to display and select from the URL commands displayed.
, which gives you access to the Control menu, and incorporates Windows buttons, Minimize, Restore/Maximize and Close.