Scenario GUI

Introducing Scenario GUI A scenario specifies the mix of different users accessing web application and hence executing different test scripts. Users may be grouped in different groups and have different user characteristics. Scenario is the overall definition of a test. Scenario may have one or more groups. Each group consists of a number of virtual users executing a test script.

Key Features of Scenario GUI Schedule Settings Global Settings Group Based Settings

SCHEDULE SETTINGS

Schedule Settings Figure: Schedule Setting Screen

Design Screen The Scenario Setting Controller has following 4 panes: 1. Scenario Settings Pane 2. Scenario Schedule Options Pane 3. Global Schedule Pane 4. Schedule Graphs Pane

1. Scenario Settings Pane A scenario is the overall definition of a test. A scenario has one or more scenario groups. A scenario consists of groups of Vusers, which emulate human users interacting with application executing a test script. Virtual User is the software simulation of real world user and a session represents what it does. The Scenario Setting Pane allows the following actions to be performed in order on a Virtual Scenario Group or Vuser Groups.

Scenario Settings Pane Screen

Create a Vuser group. Group Name User Profile Type Use “Green Plus[+]” tool to create Virtual Group. The following options are mandatory in Adding a Virtual Group Group Name The Virtual Group should be a proper name specifying the exact task the group performs. Name can be alphanumeric but first character should be an alphabet. User Profile The User Profile is User Location based. An existing User Profile from dropdown can be selected. The default is “Internet”. Type The options are: Script An existing script can be selected from dropdown list. The script name should be self explanatory. e.g. QAT_Smtp_Include_Body Session / URL A URL name is the name under test for performance. The URL name has to be typed as per exact format. Eg. http://www.Aol.com/ or https://www.KotakBank.com/ (Note: ensure that URL is ended by slash “/”)

Quantity Quantity is measure of number of Virtual users assigned to the Virtual Group. Modify an existing Virtual Group. Use “Line tool” to modify a Virtual Group. All options above Group Name, User Profile, Type & Quantity can be modified for a Virtual Group Save the Virtual Group. Use “Save tool” to save changes to a Virtual Group Use “Save” tool to save after adding / modifying a Virtual Group. Remove / Delete an existing Virtual Group. Select a group to be deleted and confirm deletion again. Run an existing Virtual Group Use “Run tool” to run the scenario Virtual Group. A new window opens while running.

2. Scenario Schedule Options Pane The Scenario Schedule Pane allows the following actions to be performed in order on a Virtual Groups.

Schedule By Scenario Schedule Type There are two “Schedule Type” in scenario. Schedule Type – Simple Schedule Type – Advanced Schedule By The Scenario “Schedule By” is of two types. Schedule By – Scenario Schedule By – Group Following are the 4 types of scenarios : Simple Scenario Simple Group Advance Scenario Advance Group

Distribute Users across Groups Distribute – By Percentage Users can be distributed across groups by two modes. Distribute – By Percentage Users in Group(s) are classified by Percentage. Eg. Group A has 80 % users and Group B has 15 % and Group C has 5 %. Distribute – By Numbers Users in Group(s) are classified by Numbers. Eg. Group A has 80 users and Group B has 20 users. Distribute – Auto Mode This mode is operational only for advanced scheduling in which users are automatically distributed according to schedule.

3. Global Schedule Pane Allows the following actions to be performed on a Virtual Groups. The Global Schedule Pane displays by default first four Phases: Start-Up Phase, Ramp- Up Phase, Stabilization Phase, Duration Phase, Ramp –Down Phase.

Global Schedule Pane

3 Global Schedule Pane – Phases 3.1 Start - Up Phase 3.2 Ramp - Up Phase 3.3 Stabilization Phase 3.4 Duration Phase 3.5 Ramp – Down Phase

Double click on ‘Start’

3.1 Global Schedule: Start-Up Phase The "Start-Up" phase means time duration of starting of operation. The following actions can be configured in Start up phase. Assign a proper name to the Start-up phase. Ex. QAT_Smtp_Include_Body_Start Select the Scenario Group to start “Immediately” after Scenario begins. Define time in (HH:MM:SS) after which scenario starts. Schedule the start immediately after a Scenario Group finishes execution. The schedule can be started after insertion of time delay in (HH:MM:SS) after a Scenario Group finishes execution. Timings statistics is collected for the whole test run before start of test. This duration (optional) is notional and is incorporated to do pre start-up checks, before the actual operations start.

Ramp – Up Phase

3.2 Global Schedule: Ramp- Up Phase The "Ramp-up" phase means an action of mounting any sort of operation. This phase is needed so that in test execution of a scenario, users are ramped by spacing them appropriately. This ramping up reduces overload on Servers. Assign a proper name to the Ramp-up phase. Eg. QAT_Smtp_Include_Body_Ramp

Ramp-up can be in any of the four ways. 3.2.1 Immediate Ramp-up Selecting “Simultaneously”, will result in all virtual users of the Virtual Group to access site "Immediately". This is called "Immediate Ramp-up". E.g. 80 Virtual users access site instantly for a group. 3.2.2 Stepwise Ramp up Select a specific number “x” of Virtual users to repeatedly access a site after inserting time delay in (HH:MM:SS). The users are ramped up in steps. E.g. 25 Virtual users are ramped-up followed by next 25 after a delay of 5 seconds, till all 100 are accessing the site. 3.2.3 Time Mode Ramp-up All Virtual users access site after inserting time delay of (HH:MM:SS) This is called "Time Mode Ramp-up". E.g. 100 Virtual users ramp-up after inserting time delay of (HH:MM:SS). This Time Mode Ramp-up can be further achieved by 2 modes. 3.2.3.(i)1 Linear Time Mode Ramp-up 3.2.3(ii) 2 Random Time Mode Ramp-up

This Time Mode Ramp-up can be further achieved by 2 modes 3.2.3.(i) 1 Linear Time Mode Ramp-up User’s ramps linearly means that the users are created at a constant inter arrival time. All Virtual users access site after inserting time delay of (HH:MM:SS). System decides to pick a fixed number of users to Ramp-up. This is Linear Time mode ramp-up. E.g. System decides to Ramp-up in say 25 users after every 5 seconds till all 100 users are ramped –up. 3.2.3.(ii) 2 Random Time Mode Ramp-up System decides to pick a fixed number of users randomly to Ramp-up. This is Random Time mode ramp-up. E.g. System decides to Ramp-up in say 20 users after every 5 seconds then ramps up 30 after delay of further 5 seconds and later ramps up 10 users and so on till all 100 users are ramped –up.

3.2.4 Rate Mode Ramp-up 3.2.4 (i) 3.2.4(ii) 1 Linear Rate Mode Ramp-up Specify a fixed number of Virtual users to ramp –up in a specified time in “Second”, OR “Minute”, OR “Hour”. This is called "Rate Mode Ramp-up". This Rate Mode Ramp-up can be further achieved by 2 modes. (Note: this option will be activated by un-checking the check box.) 3.2.4 (i) 1 Linear Rate Mode Ramp-up User’s are created at a constant inter arrival time. System decides to pick a fixed number of users to Ramp-up. This is Linear Rate mode ramp-up. E.g. 20 Virtual users ramp-up followed by delay per 1 second, next 20 users ramp-up and after further 1 second delay, 20 more users ramp up and so on. 3.2.4(ii) 2 Random Rate Mode Ramp-up Specify a fixed number of Virtual users to ramp –up randomly in a specified time in “Second”, OR “Minute”, OR “Hour”. System decides to pick random number of users randomly to Ramp-up This is Random Rate mode ramp-up. E.g. 20 Virtual users ramp-up followed by delay per 1 second, next 30 users ramp-up and after further 1 second delay, 10 more users ramp up and so on. Default Rate Mode Ramp-up The default time is 120 users per minute for our system.

3.3 Global Schedule: Stabilization Phase

3.3 Global Schedule: Stabilization Phase The "Stabilization" phase means the time delay when inserted in (HH:MM:SS), after which the application is assumed to be stable and in equilibrium after the Virtual Users is ramped up. This phase is needed to allow for server to stabilize for the peak load and also gather timing statistics. Assign a proper name to the Stabilization phase. Eg. QAT_Smtp_Include_Body_Stabilize   This phase is cut out from following next "Duration Phase". This phase is incorporated to gather data for reporting purpose on assumption that application has stabilized. Ex: The stabilization phase can be set to a value of 30 seconds.

3.4 Global Schedule: Duration Phase

3.4 Global Schedule: Duration Phase The "Duration Phase" phase means the specified time for which the process runs without any change in any parameters. Assign a proper name to the Duration phase. Eg. QAT_Smtp_Include_Body_Duration This Duration phase can be further achieved by 3 modes.   1 Time Mode Duration Phase This Time Mode duration phase means that the Scenario runs for a specific defined time. Select the “Run for” option and specify number of days and time delay in (HH:MM:SS). This is called "Time mode Duration Phase". E.g. The 100 Virtual users accessing a site will remain there for say, “1” day, “01:12:24”, i.e., 01 hour, 12 minutes & 24 second. 2 Session Mode Duration Phase This Session Mode duration phase means that the Scenario runs for a specific number of sessions. A script has a well defined structure and keeps documentation of web application user actions. A script emulates a web users activity. A script can be executed several times during a test. Each execution instance of a script is called a Session. E.g. The 100 Virtual users accessing on a site will complete their number of sessions. 3 Indefinite Mode Duration Phase This phase means that the Scenario will not stop On selection of “Run Indefinite” mode is set to "Indefinite mode Duration Phase" for our system. This is called "Indefinite mode Duration Phase". E.g. The 100 Virtual users accessing a site will remain there for indefinite time.

3.5 Global Schedule: Ramp – Down Phase

3.5 Global Schedule: Ramp – Down Phase The "Ramp-down" phrase means a gradual decrease in no of Virtual Users from system. This is reverse of Ramp-up Phase. Assign a proper name to the Ramp –Down. Example. QAT_Smtp_Include_Body_RampDown Ramp –Down can be done by any of the three ways. 1 Immediate Mode Ramp-Down Phase Selecting “Simultaneously”, will result in all virtual users to be removed from site "Immediately". This is called "Immediate Mode Ramp-Down". E.g. The 100 Virtual users accessing a site are removed from the system immediately. 2 Step Mode Ramp-Down Phase Select a specific number “x” of Virtual users to repeatedly access a site after inserting time delay in (HH:MM:SS). This is "Step mode Ramp-down phase". E.g. 25 Virtual users are ramped-down followed by next 25 after a delay of 5 seconds, till all 100 users are removed from the site. 3 Time Mode Ramp-Down Phase

3.5.1 Time Mode Ramp-Down Phase All Virtual users are removed from system after inserting time delay of (HH:MM:SS). This Time Mode Ramp –Down can be done by any of the two Ways 3.5.1(i) 1 Time Mode Ramp-down – Linearly All Virtual users are removed from system after inserting time delay of (HH:MM:SS) in a Linear mode. System decides to pick a fixed number of users to Ramp-up. This is Linear Time mode ramp-down. E.g. System decides to Ramp-down say 20 users after every 5 seconds and so on till all 100 users are ramped –down. 3.5.1.(ii) 2 Time Mode Ramp-down – Randomly All Virtual users are removed from system after inserting time delay of (HH:MM:SS) in a Random mode. System decides to pick a fixed number of users to Ramp-down. This is Random Time mode ramp-down. E.g. System decides to Ramp-down say 20 users after every 5 seconds, followed by 10 users in next 5 seconds followed by 30 users ramped down in next 5 seconds and so on till all 100 users are ramped –down.

 4. Schedule Graphs Pane The Scenario Schedule Pane allows viewing progress of a Scenario across different phases in Virtual Users Vs Time axis graph.

Scenario Schedule Examples

Simple Scenario – Number Mode SGRP G1 ….. 200 SGRP G2 …… 300 Start all VUsers … Duration of 10 minutes Stop all Vusers ….

Simple Group - Number Mode SGRP G1 ….. 200 SGRP G2 …… 300 G1 Schedule Start group Start all VUsers … Duration of 10 minutes Stop all Vusers …. G2 Schedule Start group after G1

Advanced Schedule – Scenario Based - Number Mode SGRP G1 ….. 200 SGRP G2 …… 300 Start 100 VUsers … Start 200 VUsers … Duration of 10 minutes Stop 100 Vusers …. Stop all Vusers …. (it will stop all remaining users)

Advanced Group Based - Number Mode SGRP G1 ….. 200 SGRP G2 …… 300   G1 Schedule Start group Start 50 VUsers … Start 100 VUsers … Duration of 10 minutes Stop 50 Vusers …. Stop all Vusers …. (it will stop all remaining users) G2 Schedule Start group after G1 Stop 200 Vusers ….

GLOBAL SETTINGS

GLOBAL SETTINGS We can apply following type of settings through “Global settings” screen of Scenario GUI: Scenario Types Monitors IP General Logs & Reports HTTP Performance Advance Settings Ramp down setting

GLOBAL SETTINGS - Scenario Types

FCU FCU Advance Simple Scenario Based Group Based Scenario Based

GLOBAL SETTINGS - Scenario Types Following are the scenario types supported by Netstorm:  Manual Scenario: Fix Concurrent Users : The number of concurrent users accessing the SUT(System under test) is fixed Fix Session Rate : The session rate (per minute) to which the SUT is exposed is fixed Mixed Mode :  This mode is a combination of FCU and FSR. Goal Based Scenario: Fix Mean Users   : The concurrent users would vary around a mean. It is different than Fix Concurrent Users where Concurrent users are always fixed.  Fix URL Hit Rate (Hits/Min) : Target URL hit rate at SUT is fixed. Fix Page Hit Rate (Pages/Min): Target Page hit rate on the SUT is fix. Fix Transaction Rate (Transactions/Min): Target Transaction rate is fix.

GLOBAL SETTINGS - MONITORS

GLOBAL SETTINGS - MONITORS Monitors: Monitors are special programs used for following purposes: Get Server data Get Logs Check server status Monitors can perform following tasks: Generate data Generate event FTP files from server to NetStorm machine   Need of Monitors: To Monitor the Server health. To get the important data from the Server. Check Monitors- Monitors whose job is to do miscellanies tasks such as checking health of the system, ftp of logs files, running some command and capture output in file. Default time out for running pre test check monitor is 15 sec. Default time out for running post test check monitor is 300 secs. Scenario Associated Monitors Group(s): This window is used to add desired monitor profile in scenario.

GLOBAL SETTINGS - MONITORS Steps for adding a Monitor profile: Go to Global settings window Click on Monitors tab Select any Monitor profile from the drop down menu as shown below Click on ADD button. Click on SAVE and then OK button.

GLOBAL SETTINGS – IP There is a need for NetStorm to support multiple sources IP addresses for following reasons.   Real users use different source IP addresses and hence to emulate the real-world scenarios NetStorm should be able to generate virtual users with different source IP addresses. When NetStorm generates a very high connection rate, system can run short of IP addresses/ports combinations for creating new connections. Ports are limited to 64K and hence having several sources IPs may be required. There is a need for NetStorm to support multiple servers IP addresses for following reasons. Real servers use different IP addresses and hence to emulate the real-world scenarios NetStorm should be able to connect to different servers different server IP addresses. When NetStorm generates a very high connection rate, system can run short of IP addresses/ports combinations for creating new connections on server side. Ports are limited to 64K and hence having several destinations IPs may be required.

GLOBAL SETTINGS – IP To setup IP configuration, Click Goal Based Settings button on Scenario Setting screen and then click on IP Tab. The default screen appears which is shown below:- Define scenario tab -> Goal based setting -> IP tab. User will get following options here:

GLOBAL SETTINGS – IP Use only Admin IP address. All virtual users share a pool of IP addresses. In this option two users can have same ip. The three options are available for this: a)Use all Load Interface IP addresses. If user want to use the all assigned IPs in the scenario. b) Use _X_ Load Interface IP addresses. If user want to use the ‘x’ assigned IPs out of alll assigned IPs in the scenario.  c) Use following IP addresses: In this, user will give IPs which user wants to use. In this it will show a list of assigned IPs and user has to choose IPs from that list only. All virtual users get a unique IP addresses. In this option two users cannot have same ip. a) Use all Load Interface IP addresses. If user want to use the all assigned IPs in the scenario.   b) Use _X_ Load Interface IP addresses. If user want to use the ‘x’ assigned IPs out of all assigned IPs in the scenario.

GLOBAL SETTINGS – GENERAL

GLOBAL SETTINGS – GENERAL General window contains following options:   Health monitor: Whenever NetStorm starts the execution of the new scenario then each and every time it checks the health of the System i.e. how many Socket connections are in use currently. After analyzing the sockets for System i.e. the time-weighted socket in the system should be less than 1000, after that it gives the permission of execution of Scenario, otherwise it will wait for 3 sec and analyze again. Internet Simulation : If we want to enable Internet simulation then we have to check this option . By default the simulation is off. Process Log Data After Text Execution : Process Log Data After Test Execution is used for enabling or disabling the Log Data processing. By default this option is enabled. Test name : This is used to specify a name to the test which is going to be executed so that it can be uniquely identified.

GLOBAL SETTINGS – GENERAL Enable Transaction Cumulative Graphs : This is used to enable or disable transaction cumulative graph. By default this is disabled.   Pages As Transaction: This option is used to enable or disable the transaction. It contains following options: Do not consider page as transaction : When this option is selected then transaction will not be applied on the pages. By default this option is enabled. Consider all page status as one transaction : When this option is selected then transaction will applied on all the pages of the script .By default this option is disabled. Consider success and failure as two different transactions : When this option is selected then two transactions will applied on the pages of the script used in the scenario separately one transaction is for success and another is failure. By default this option is disabled. Consider different page statuses as different transactions : When this option is selected then different transactions will applied on the all pages of the script used in the scenario so that one transaction defines only one page. By default this option is disabled.

GLOBAL SETTINGS – LOGS AND REPORTS

GLOBAL SETTINGS – LOGS AND REPORTS The various options available are explained below: Maximum Debug Log File Size : This helps to define a maximum size for our debug log file .once the file size becomes equal to the size mentioned in the text box then ,a new file is created automatically with the name of debug.log.prev and the new data goes to a new file called debug.log. By default size is 100 MB. Maximum Error Log File Size : This helps to define a maximum size for our Error log file .once the file size becomes equal to the size mentioned in the text box then ,a new file is created automatically with the name of Error.log.prev and the new data goes to a new file called Error.log. By default size is 10 MB. Show initiated request counts for URL, Page, Transaction and Session in the progress report : This shows the initiated request counts for URL, Page, Transaction and Session in the progress report. when it is selected the initiated transactions detail will be displayed. One can see these by clicking on to Transaction report on the RTG screen. By default it is disabled. Show counts in the progress report Periodic Count Cumulative Count :Show counts in the progress report. 0 :- Both periodic and cumulative. 1 :- Periodic. 2 :- Cumulative Enable Debug Trace Exclude failed Page, Transaction and Session in the report Enable SSL library trace  

GLOBAL SETTINGS – LOGS AND REPORTS Percentile Report :  A percentile is the value of a variable below which a certain percent of observations fall. So the 20th percentile is the value (or score) below which 20 percent of the observations may be found .this keyword is basically used to have the graphical representation of the percentile report in the GUI analysis screen. When Enable percentile report. Percentile raw data collection , then following options appear : URL response time percentile definition file Page response time percentile definition file Session response time percentile definition file Transaction response time percentile definition file Per transaction response time percentile definition file   Event log: An occurrence or happening of significance to a task or program, such as the completion of an asynchronous input/output operation . A task may wait for an event or any of a set of events or it may (request to) receive asynchronous notification (a {signal} or {interrupt}) that the event has occurred. We can also filter events based on requirements. Event Log Levels: There are 5 levels. They are Info, warning , minor , major & critical. Event Log level specifies which level of events are logged. For example: If level is warning, all events with level warning or higher level are logged. Events are further filtered using filter level before logging in the event log file. Enable Log Manager: Enable Log manager will start NetStorm logging manager process. Each process will send events to log manager using TCP/IP. Filtering will happen at system level (Default).Disable Log manager will not start NetStorm logging manager process. Each process will write event in the event log file directly. Filtering will happen at process level.

GLOBAL SETTINGS – HTTP

GLOBAL SETTINGS – HTTP Progress Report Interval : This is used for display the progress detail with specified interval in the progress detail. Time will be in millisecond. But in the GUI one has to give this value in the seconds only. NetStorm automatically covert it in to milliseconds. SSL Settings: SSL Ciphers : SSL ciphers specifies the server authentication algorithm, the key exchange algorithm, the bulk encryption algorithm, and the digest algorithm. SSL Certificate File name with path : SSL Certificate filename with path to be used for client authentication. SSL Key File name with path : It is also used for Client Authentication. Other Settings : Enable Auto Cookie: Used to make cookies in HTTP request based on the Set-Cookie header received in the HTTP response header. Cookies in the script files which were captured during recording are ignored. Disable Cookie : Used to disable cookies in the HTTP request. No cookies will be send in the HTTP request. Enable Auto redirect up to depth: Used to follow redirects based on the HTTP response. Depth controls how many redirects will be handled for one URL. Use 0 depth to disable auto redirect. If auto redirect is enabled, then redirected URL(s) in the script files which were captured during recording are ignored. If use parent URL method for redirected URL is selected, then parent method (GET/POST) is used in the redirected URL request. Otherwise GET method is used.

GLOBAL SETTINGS – PERFORMANCE

GLOBAL SETTINGS – PERFORMANCE Number of Processes : Initiated on Either CPU or Machine This is used to generate netstorm processes as described by the user. The processes can be initiated on either the CPU ( which can be 2 to 4 in a system) or on the MACHINE .By default value is 2 and initiated on CPU. The difference between the two can be understood the by the examples . Example: when we enter number of process as 2 and initiated on “MACHINE” It will take 2 processes on machine. Here, we see that the number of processes made is 3 , ie. 2 Processes mentioned in the keyword and 1 parent process. So that makes it 3 processes. Formula: Total number of processes = Number of MACHINES + 1   when we enter number of process as 2 and initiated on “CPU” If one gives this value ( we assume that the number of CPU’s working are 2), then the number of processes that will be generated would be 5, ie 2 processes per CPU and 1 parent process.   Formula: Total number of processes = 2 * (Number of CPU) + 1 Maximum Connections per Virtual User : Maximum number of connections to be used by a Virtual User . Default is 8 connections per virtual user.  Free kernel socket memory after keep alive connection finished the request :   When this option is enabled then memory will be freed after the request is completed.

GLOBAL SETTINGS – PERFORMANCE Optimize Ethernet packet flow Handshake Merge Acknowledge It is used to control the merging on the acknowledge during handshake connection Disabled: This is default. In this case, no merging is done to reduce number of packets. Enabled: This will result in piggybacking of ACK with other packets as and when possible during handshake. If used in client side and client is making connection (which is the case), then ACK of SYN and Data will be merged. This will result in reduction of packets by 1 

GLOBAL SETTINGS – PERFORMANCE Data merge acknowledge: It is used to control the merging on acknowledge during data communication. Disabled: This is default. In this case, no merging is done to reduce number of packets. Enabled: This will result in piggybacking of ACK with other packets as and when possible during data communication. If used in client side, then ACK and FIN will be merged. This will result in reduction of packets by 1. Close by reset : Disable: This is default. In this case, connection will be closed gracefully using FIN. Enable: This value will close the connection by sending TCP Reset (RST) instead of FIN. No packets will be send back from other side. This will result in reduction of packets by 2 if close is done by the side where this option is used.  Enable high performance mode:   Maximum sockets per NVM to be allocated for high performance mode:    Java Script Runtime Memory: Specify Memory for JavaScript Runtime environment. It has following values: 0: Per NVM 1: Per virtual user.  Time stamp method: Time Stamp method 0: This is default. In this case,Use Kernel Jiffy. 1: Use rdtsc clock. 2: Use gettimeofday() API. Enable SSL High Performance Mode

GLOBAL SETTINGS – ADVANCE SETTINGS

GLOBAL SETTINGS – ADVANCE SETTINGS Auto distribution for maximum performance. A scenario group may be distributed over 1 or more NVM's: Auto distribution for maximum isolation among scripts. All scenario group using same script will be executed only by one NVM:   User specifies NVM Id for each scenario group :

GLOBAL SETTINGS – RAMP DOWN SETTINGS

GLOBAL SETTINGS – RAMP DOWN SETTINGS It defines various methods in which virtual users are ramped down. Ramp down condition can be applied in following ways. Allow current sessions to complete: Ramp down settings are applied after completion of current session Allow current page to complete: Ramp down settings are applied after completion of current page. Stop Immediately

GROUP BASED SETTINGS

Group Based Settings We can apply following type of settings through “Group based settings” screen of Scenario GUI: Page Think Time Session Pacing Auto Fetch HTTP Setting General Settings Logs Service Options Page Reload Click Away

Group Based Settings - Page Think Time It is really un-realistic for any real user to just keep clicking the pages one after the other without pausing to look at it. The user spends some time in viewing the pages that are downloaded. The average viewing time depends upon the page contents & the user’s familiarity of the page. Each Page may be assigned a think time. If a think time is not associated with a specific page, default Page think would be used for such pages. Page Think Time is also called the Page View Time (after a page is downloaded). To setup Think Time configuration, Click Group Based Settings button on Scenario Setting screen and then click on Think Time Tab. The default screen appears which is shown below:-   On clicking the Think Time Tab ,the default window for the Page Think Time will open which contains Think time Options.

Group Based Settings - Page Think Time

Group Based Settings - Page Think Time Think Time Options No Think Time: No time is spent in viewing the pages. Random (Internet type distribution) think time with median of value specified in seconds. The think time is taken randomly in internet type distribution pattern with median of the value specified. For internet type distribution, median is roughly around ¼th of the mean. Constant think time of value specified in seconds. By choosing this option constant think time can be taken for each page. Random (Uniform distribution) think time from specified range in seconds. It will randomly take the value of think time from the range specified in uniform distribution.

Group Based Settings - Page Think Time OVERRIDE RECORDED THINK TIME   This is used, when the API {ns_set_page_think_time <value>} has been defined in any of the pages mentioned in the script used .Then this keyword overrides the setting of the page think time for the particular pages. To override recorded think time following options are available: Using above scenario settings : when select this option then the page think time will be same as above defined page think time. Multiply recorded think time by some value (default value is 0): when select this option then we have to give the number so that the given page think time is multiplied by the value given in this textbox. Use random percentage of recorded think time from minimum % to maximum %(default=0) When select this option then give the min and maximum % value so that the page think time will be the in between the minimum and maximum % of the above given page think time.

Group Based Settings - Page Think Time ADD GROUP When we want to give think time option to any specific group then we can choose “Add group” option. Following window is displayed: Figure: Page Think Time window  Here the name of group is g1. We can select any specific page of the script and can apply the above settings for that particular page. The options available are same as above.

Group Based Settings – Session Pacing Pacing is related with rate of speed. Load on the server does not simply depend upon the number of concurrent users. The pace at which a virtual user is generating session is also equally responsible for the load on the server. Since, pacing is a key element in load determination, it is important that Pacing configuration for a scenario is realistic. After a virtual user has completed executing a test script, it would start executing the next iteration of the session associated with its scenario group. The timing of next iteration of session execution depends upon the pacing configuration of the session. If No Pacing configuration for a session is defined, the default pacing is used for such sessions. Default Pacing is specified by specifying PACING for reserved script named ALL.-- Click the session pacing button option on the Group Based Setting Window.

Group Based Settings – Session Pacing

Group Based Settings – Session Pacing “Start New Session “ specifies when the next session is started after a vuser completes previous session. It can have one of the possible values: As soon as the previous session ends: This mode is good for loading the SUT maximally. (Default mode) After the previous session ends: The new session starts after the end of previous session in following three ways: With fixed delay (the next session will be started after a fixed delay) With random (Internet type distribution) average delay (The delay will be random average delay of the time specified) With random (Uniform distribution) delay (The delay will be of random but uniform and within the range specified.  Once every interval (Provided that the previous session ends by that time else next session starts as soon as previous session ends) At fixed interval At random (Internet type distribution) average interval At random (Uniform distribution) interval

Group Based Settings – Session Pacing Example: Consider a situation where previous session took 10 seconds, and we have pacing time of 15 seconds. In this case, next session would be started after 5 seconds of completing the last session. This mode try to keep the average session rate same even if the server response time changes. This is more akin to real life situations where the typical session rate (sessions/hours) does not change for an application, if the response time has increased. If the last session takes more than pacing time, next session would be started immediately after completing previous session.

Group Based Settings – Session Pacing ADD GROUP When we want to give session Pacing option to any specific group then we can choose “Add group” option. Following window is displayed: Figure: Session Pacing Option window Here the name of group is g1. We can select any specific page of the script and can apply the above settings for that particular page. The options available are same as above.

Group Based Settings – AUTO FETCH

Group Based Settings – AUTO FETCH Netstorm fetches URL based on the recorded scripts. But many web applications have dynamic contents which changes based on the time, place and other factors. Also contents may change from release to release. So to do realistic testing and to avoid reordering of script with every release, Auto Fetching of embedded objects is required. So , the concept of auto fetch is used to fetch embedded urls from real site. Fetch option: It specifies fetch option of the session Fetch Every time Disable Auto Fetch Steps to apply Auto fetch: Go to Global setting pane Click on Auto Fetch option Add a group Select page from Page Name drop down menu Select fetch option Click on ADD button

Group Based Settings – HTTP SETTINGS

Group Based Settings – HTTP SETTINGS Enable browser Cache : This is used to enable caching for (Pct-user 0 to 100 (up to 3 decimal)) with following options No caching across sessions for same user Enable Client freshness Java Script: This is used to enable or disable java script HTTP No Activity Timeout : It specifies the HTTP and HTTPS time out. HTTP and HTTPS request will remain alive for given time and after it will no longer exist. Default is 60 seconds. Keep Alive Connection Percent : Keep Alive Connection is a percent value which specifies the percentage of total connection initiated by NetStorm and it tries to reuse the connection.

Group Based Settings – HTTP SETTINGS Keep – alive timeout for HTTP protocol : Mode of keep alive timeout. It has following values: 0 – No keep alive time out (default) 1 – Browser based keep alive time out. 2 – Group based keep alive time out. Average keep Alive Request Per Connection (Min & Max) : Minimum & Maximum value of the requests that would be made on a single connection which is remaining as keep alive. Number of Retries on connection , SSL or request Failure : Number of retries to be made by the NetStorm on connection, SSL or request failures for a particular URL. Perform no validation on response : Specify that no validation required on page response. Get Only Main Page Objects (Do not fetch inline images, js, css etc): Used to specify that inline objects and images is to be displayed on main page or not.

Group Based Settings – HTTP SETTINGS Enable HTTP Referer header   HEADER SETTINGS : It is used to enable or disable following type of headers: Host Header User Agent Header Accept Encoding Header Connection Header Accept Header Keep Alive Header SSL SETTINGS : Average SSL Reuse % : Percentage of SSL sessions to be reused SSL Clean Close : SSL clean close only. OTHER SETTINGS : Use recorded host in host header : Use Recorded Host in 'HOST' Header. By default mapped host is used in the 'HOST' header Disable Reuse of TCP/IP Address : Used to disable reuse of TCP/IP Address. Fail page if embedded URL of a page fails

Group Based Settings – GENERAL This tab describes about the status of the pages during the execution. This tab also describes the error code, run script mode. After clicking on the general tab , following window will open with following options:

Group Based Settings – GENERAL General tab contains following options : Continue On Page Error : If continue on page error is enable, netstorm executes all pages even if page is failing due to any error. By default netstorm stops execution of the script as soon as page fails Error Codes ok : If there is any error coming with error codes 1xx , 2xx and 3xx then netstorm assume that the request is successful. After an old user completes a session, user connection remains open for specified milliseconds. Run Script Mode : Run script mode for Legacy and User Context

Group Based Settings – LOGS Log tab is used to configure logging settings, Tracing settings and Reporting setting for scenario groups. Each test run is assigned a sequentially generated number. For each test run a log directory is created by the name TRxxx, where xxx is the test run number, under the logs directory. Test run logs directory contains logs. Logs are created for storing record of any test run.  After click the Log tab , a logging window will open which contains Logging ,Tracing and Reporting options:

Group Based Settings – LOGS Logging Window contains following options : Logging Tracing Reporting Logging : Logging settings control what logs will be logged in the test run log. Test Scripts may log user messages using ns_log_msg () NS Function. Logged messages have a log level associated with it. Log level specifies the verbosity of the message. Messages with higher log level, represents higher level of verbosity. At run time, the log messages are enabled by checking appropriate logging settings. Logging settings are group based. You can specify different settings for different scenario groups. If for a group settings are not defined, then it will take same settings as for default group.

Group Based Settings – LOGS Logging contains following options : Log Level : Log level specifies up to which level logs are enabled. All messages belonging to log-level and below are enabled. Possible values of log level are: No logs enabled Only logs logged with Standard Log Level are enabled Logs with Standard and Extended log level are enabled All logs (standard, extended and debug are enabled).

Group Based Settings – LOGS Log Destination : Destination specifies where the logs are logged. Possible values are: log only to standard out (screen) log to file only log to both standard out and logs By default, Standard logs are logged to standard out. All other logs messages are disabled. Logs coming on standard out are redirected to Test Run output file (TRxxx/TestRunOutput.log) if test is run from GUI.When the logging to file option is enabled, messages are logged to TRxxx/log. xxx is the Test run number. Also, these messages can be viewed only after the completion of the test run.

Group Based Settings – LOGS Tracing : NetStorm logs important messages. These logs are called traces. NetStorm user just has to enable the traces to see them. Tracing settings are group based. You can specify different settings for different scenario groups. If for a group settings are not defined, then it will take same settings as for default group. Log tab is used to configure Tracing settings for scenario groups. Trace Level : All messages belonging to trace-level and below are enabled. Possible values of trace level can be: No trace enabled Only URL failure notifications are enabled URL Failure Notification and parameter substitution are enabled URL Failure Notifications, Parameter substitution and URL responses are enabled URL Failure Notifications, Parameter substitution enabled and response

Group Based Settings – LOGS Trace Destination : It Specifies where the logs are logged. Possible values are: log only to standard out (screen) log to file only log to both standard out and logs Tracing Record :It Specifies the condition when the trace messages are logged. Possible values are Trace all URL interactions Trace only failures The default value of this field is 1 (Trace only failures). This is an optional fields and is only checked (if provided) when trace-level is 2. Limit Trace Record size:

Group Based Settings – LOGS Limit Trace Record size: It is the maximum size of the trace message that should be logged. 0 means log the complete response without limiting its size. The default value is 4096 bytes. This is an optional field and is only checked (if provided) when the trace-level is 2. By default, Only URL failure notifications are enabled. All other trace level is disabled. Logs coming on standard out (screen) are redirected to files log, or page_dump.txt and page_dump.html (TRxxx/slog)..When the tracing to Standard Out(screen) option is enabled, messages are logged only to the screen. Also, these messages can not be viewed after the completion of the test run. When the tracing to file option is enabled, messages are logged to page_dump.txt and page_dump.html files in TRxxx/log. xxx is the Test run number. Also, these messages can be viewed only after the completion of the test run.

Group Based Settings – LOGS REPORTING : Various kinds of reports can be generated for a test run by netstorm and to enable these reports we use this keyword and use its parameters (0 to 3) for various levels of reports. Report Level only summary reports will be generated summary and runtime reports will be generated ( which is default) summary, runtime and detailed reports will be generated summary, runtime, detailed reports and run time graphs will be generated Syntax: G_REPORTING <Report-level>

Group Based Settings – LOGS All messages belonging to report-level and below are enabled. Possible values of report level can be:   0 :-only summary reports will be generated 1 :-summary and runtime reports will be generated ( which is default) 2 :-summary, runtime and detailed reports will be generated 3 :-summary, runtime, detailed reports and run time graphs will be generated Note: The 0 & 1 report level includes Summary & Progress reports. The 2 & 3 report level includes Summary, Progress, Detailed, Failure, Page Breakdown reports. The .csv files are generated in TR when we use reporting keyword in scenarios. These .csv files import the data into the database. We need these .csv files to recreate the database. The 2 & 3 options generate the drill down report into the Report Selection GUI

Group Based Settings – LOGS ADD GROUP When we want to give log option to any specific group then we can choose “Add group” option. Following window is displayed: Figure: Log Option window Here the name of group is g1. We can select any specific page of the script and can apply the above settings for that particular page. The options available are same as above.

Group Based Settings – LOGS

Group Based Settings – SERVICE OPTIONS With log system implemented, it becomes easy to understand the flow of the execution. So it would be easy to catch the shortcomings of the design or of the code at the unit testing time only. It would be very beneficial for giving the client a good and quality code. Enable/Disable based on module: User should be able to disable or enable the debug log as per the requirement for a particular module. Different log levels There are different log levels, each specifying the increasing depth of log statements. Steps to configure service options : Step :1 Click Group Based Settings button on Scenario Setting screen Click the Group Based Setting option on the scenario window. On clicking the Group Based Setting button , Group Based Setting window will be open After click the service option tab , a Service Options window will open which contain Debug level and Other Keywords as shown below: Service Options window contains Debug Levels , Module Masks and Other Keywords Debug Levels Debug level is used to specify what level of logs user wants to enable for logging. The value of the debug level ranges from 0 to 4.

Group Based Settings – PAGE RELOAD INTRODUCING PAGE RELOAD Page Reload means “To download again the same Web page currently on screen in case it changed at the server side since it was last downloaded.” We are stopping loading of the current page after the timeout and loading same page again.   Step to configure Page Reload : Step :1 Click Group Based Settings button on Scenario Setting screen Click the Group Based Setting option on the scenario window. On clicking the Group Based Setting button , Group Based Setting window will be open

Group Based Settings – PAGE RELOAD

Group Based Settings – PAGE RELOAD

Group Based Settings – PAGE RELOAD A given page has to be reloaded if its response time is greater than given time out msecs. Reload can be attempt at random number between min & max given. If response time is found less than given time out it means page is reloaded successfully, so no more attempt else reload the page again. If all the attempt are completed then it has to wait for normal execution of a page. There are 3 option to reload a page : First, Given time out is only for main url of a page. Mean to say if main url response time is greater than given time out then reload the page. Currently we allow time out only for main urls. Second, Given time out is given for each url (either it is main or embedded). In this case page reload can be done in following way: If main url response time > given time out, reload the page. If embedded url response time > given time out , reload the embedded or main url. ?? Third, Time out is given for whole page including embedded url . Mean to say if main + all embedded url response time is greater than given time out then reload the page. In the above screenshot: Group Name : Group name can be ALL and Page ALL, For a group, Page can be ALL . Page : The page which is to be reloaded. We can select All pages also. Min & Max Reloads : A random number between min & max, which is used to get reload attempt. Timeout in ms : Time out to decide a page is reloaded or not.

Group Based Settings – CLICK AWAY

Group Based Settings – CLICK AWAY Group Name : Group name can be ALL and Page ALL, For a group, Page can be ALL Page : Page index from where to click away. (Must be a valid page index) Next page : Page which has to execute on Page Click Away. (Only -1 can be given for Simple Scenario) Pct : Percentage is how many (%) pages is to be clicked away. Time in ms : Timeout for click away. Call check page or not : Check Page should be called or not <0/1> Note: Number of %(Pct) “Click away” a page if Main Url download time is greater than click away time given. Open transaction need to be closed with Click Away if clicking away to the exit page (I.e. -1). As we know in a normal page execution check_page for every page returns the next page to be executed. But if page click away is given for a page, then next page will not be the page which check_page has returned, it will be page which has given i.e Next page. User has to be very careful if he is using click away & transaction. It may be possible a transaction is started on page 3 & closed on page 5, but we clicked away a page 2 → 4, in that case transaction is not started but configured to end. Some warning message will come to console. If both Reload and Click Away is given, then we check Reload first, then click away. If runlogic is given & Click away is also given then we next page will be -1(End of script). Page status will be set to ClickAway.

Group Based Settings – CLICK AWAY ADD GROUP When we want to click away option to any specific group then we can choose “Add group” option. Following window is displayed: Here the name of group is g1. We can select any specific page of the script and can apply the above settings for that particular page. The options available are same as above.