Overview

In this section, user set up the scenarios and can perform actions, such as adding a group, setup scenario schedule options, setup global schedule and setup various phases. The resultant scenario schedule is displayed in the form of a graph in Schedule graph pane.

Figure: Schedule Settings

User can use a scenario profile by clicking the Profile link at the top-right corner of the Schedule settings window and providing the details, such as project, subproject and scenario profile name.

Schedule Settings Section

The Scenario Setting section allows the following actions to be performed on a Virtual Scenario Group or a VUser Group.

• Creating a VUser Group
• Modifying an Existing Group
• Removing / Deleting an Existing Group
• Running an Existing Group

Creating a VUser Group

• Click the Add Group icon to create a group. The Add Group dialog box is displayed.

Figure: Add Group

Provide the details in the following fields for adding a group:

Group Name: The group should have a proper name specifying the exact task the group performs. The name can be alphanumeric but the first character should be an alphabet.

User Profile: The User Profile is User Location-based. An existing User Profile from the drop-down can be selected. The default is “Internet”.

Type: The available options are:

• Script: An existing script can be selected from the drop-down list. The script name should be self-explanatory. For example QAT_Smtp_Include_Body
• URL: A URL name is a name under test for performance. The URL name has to be specified as per the exact format. For example, http://www.Aol.com/ or https://www.google.com/
• JMeter Script: JMeter test can be run from NS test by running JMeter instance from NetStorm. JMeter instance will run its own JMXscript. NetStorm will read data from JMeter logs and plot HTTP graphs on the dashboard.
• RDT URLs: NetStorm/RDT provides a versatile mobile application testing platform using real iOS and Android devices on the cloud. NetStorm/RDT has the largest device farm of real mobile devices, gathered from different regions globally, including the most versatile OS, OEM, and hardware configurations for Android and iOS developers. This helps in test automation, remote manual access, and REST API to access, run and manage any tests with these devices.

• To know more about RDT, ask your Cavisson representative.

Ensure that the URL is ended with a forwarding slash “/”.

Session/URL: On selecting the Type as Script, the user needs to provide the Session. On selecting the Type as URL, the user needs to provide the URL.

The number of users (s): It is the measure of the number of Virtual users assigned to the group. For example 80.

Users can add more groups in a similar manner.

Modifying an Existing Group

• Double-click the group name or select the group name and click the Edit Group icon.
• Users can edit Group Name, User Profile, Type, Session /URL & Number of the user(s) for a group.

Deleting an Existing Group

• Delete a group by selecting a group and clicking the Delete Group icon .

Running a Scenario

• Click the Start icon to run the scenario.
• The Start Scenario Dialog box is displayed.

Figure: Start Scenario 

• Enter the Test Name and click the Start Scenario button.

Scenario Schedule Options Section

The Scenario Schedule section allows the user to set schedule options to be performed on groups.  

Figure: Schedule Options Section

Scenario Schedule Type

 The Schedule Type has two options:

• Simple: Simple schedule is a schedule where there are only four phases and optionally the start phase. In the ramp-up and ramp-down, all users or session rates are ramped up or ramped down. There is no control or need to specify the number of users or session rate as the user is going to do all users or all session rates.
• Advanced: Advanced schedule is a more complex and user-defined schedule where there can be any number of phases in the schedule. In each ramp-up phase, specify the number of users or session rate to be ramped up. In each ramp-down phase, specify the number of users or All or session rate or All to be ramped down.

Schedule By

The Scenario Schedule section allows the user to set schedule options to be performed in groups.

Figure: Schedule Option Section

Distribute Users across Groups

Users can be distributed across groups by following modes:

• By Percentage: Users in Group(s) are classified by Percentage. For example, Group A has 80% of users and Group B has 15% and Group C has 5%.
• By Numbers: Users in Group(s) are classified by Numbers. For example, Group A has 80 users and Group B has 20 users.
• Auto Mode: This mode is operational only for advanced scheduling in which users are automatically distributed according to schedule.

Global Schedule Section

The Global Schedule section allows setting phases in groups. Users can Add, Delete and Edit the phases.

Figure: Global Schedule

The Global Schedule section displays all five phases by default: Start Phase, Ramp-Up Phase, Stabilization Phase, Duration Phase, and Ramp–Down Phase.

Start Phase

The Start phase signifies the time duration of starting of the operation. The following actions can be configured in the Start phase:

Figure: Start Phase

• Assign a proper name to the Start phase. For example:
• Select the Scenario Group to start Immediately after the Scenario begins.
• Define the time in the specified format (HH:MM: SS) after which the scenario starts.
• Schedule the start immediately after a Scenario Group finishes execution. The schedule can be started after the insertion of time delay (in HH:MM: SS) after a Scenario Group finishes execution.
• Timings statistics are collected for the whole test run before the start of the test. This duration (optional) is notional and is incorporated to do pre-start-up checks before the actual operations start.

Ramp-Up Phase

The Ramp-up phase signifies the 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. For example, QAT_Smtp_Include_Body_RampUp.

Figure: Ramp-Up

Ramp-up can be done in any of the four ways:

Immediate Ramp-up

Selecting the Simultaneously option results in all virtual users of the group accessing site Immediately. This is called Immediate Ramp-up. For example, 80 Virtual users access the site instantly for a group.

Stepwise Ramp-up

Select a specific number of Virtual users to repeatedly access a site after inserting a time delay (in HH:MM: SS). The users are ramped up in steps. For example, 25 Virtual users are ramped up followed by the next 25 after a delay of 5 seconds, till all 100 are ramped up.

Time Mode Ramp-up

All Virtual users access the site after inserting a time delay (in HH:MM: SS). This is called Time Mode Ramp-up. For example, 100 Virtual users ramp up after inserting a time delay of (HH:MM: SS). This Time Mode Ramp-up can be further achieved by 2 modes.

• Linear Time Mode Ramp-up

Users ramp linearly means that the users are created at a constant inter-arrival time. All Virtual users access the site after inserting a time delay (in HH:MM: SS). The system decides to pick a fixed number of users to Ramp-up. For example, the System decides to Ramp-up 25 users after every 5 seconds till all 100 users are ramped up.

• Random Time Mode Ramp-up

All Virtual users access the site after inserting a time delay (in HH:MM: SS). The system decides to pick a fixed number of users randomly to Ramp-up. For example, the System decides to Ramp-up 20 users after every 5 seconds then ramps up 30 after a delay of further 5 seconds, and later ramps up 10 users, and so on till all 100 users are ramped-up.

Rate Mode Ramp-up

Specify a fixed number of Virtual users to ramp up per Second/per Minute/per Hour.  This Rate Mode Ramp-up can be further achieved by 2 modes:

These options are activated by clearing the Default Rate check box.

• Linear Rate Mode Ramp-up

Users are created at a constant inter-arrival time. Specify a fixed number of Virtual users to ramp up per Second/per Minute/per Hour. The system decides to pick a fixed number of users to Ramp-up. For example, 20 Virtual users ramp up followed by a delay per 1 second, the next 20 users ramp up, and after a further 1-second delay, 20 more users ramp up, and so on.

• Random Rate Mode Ramp-up

Specify a fixed number of Virtual users to ramp up randomly per Second/per Minute/per Hour.  The system decides to pick a random number of users randomly to Ramp-up. For example, 20 Virtual users ramp up followed by a delay per 1 second, the next 30 users ramp up and after a further 1-second delay, 10 more users ramp-up, and so on.

The default rate is 120 users per minute for our system.

Stabilization Phase

The Stabilization phase signifies the time delay (in HH:MM:SS) after which the application is assumed to be stable and in equilibrium once all the Virtual Users are ramped up. This phase is needed to allow server to stabilize for the peak load and also gather timing statistics.

Assign a proper name to the Stabilization phase. For example, QAT_Smtp_Include_Body_Stabilize.

Figure: Stabilization Phase

This phase is cut out from the following Duration Phase. This phase is incorporated to gather data for reporting purposes on assumption that the application has stabilized. For example, the Stabilization phase can be set to a value of 30 seconds.

Duration Phase

The Duration phase signifies the time for which the process runs without any change in any settings.

Assign a proper name to the Duration phase. For example, QAT_Smtp_Include_Body_Duration

Figure: Duration Phase

This Duration phase can be further achieved by 3 modes:

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). For example, 100 Virtual users accessing a site remain there for 1 day, 01:12:24, i.e., 01 hour, 12 minutes & 24 seconds.

Session Mode Duration Phase

This Session Mode duration phase means that the Scenario runs for a specific number of sessions. For example, 100 Virtual users accessing a site run for 10 sessions. Sessions can be divided among users mentioned for that group. By using the “Run per user session” option.

Each group total sessions = no. of users * no. of sessions

Indefinite Mode Duration Phase

In this phase, the Scenario doesn’t stop if Run Indefinite mode is selected. For example, 100 Virtual users accessing a site remain there for indefinite time.

This is the default option.

Ramp-Down Phase

The Ramp-down phase means a gradual decrease in number of Virtual Users from system. This is reverse of Ramp-up Phase.

Assign a proper name to the Ramp-Down. For example, QAT_Smtp_Include_Body_RampDown.

Figure: Ramp Down Phase

Ramp-Down can be done in any of the three ways:

Immediate Mode Ramp-Down Phase            

Selecting the Simultaneously option results in all virtual users being removed from the site Immediately. For example, 100 Virtual users accessing a site are removed from the system immediately.

Step Mode Ramp-Down Phase

Select a specific number of Virtual users to repeatedly remove from the system after a time delay (in HH:MM: SS). For example, 25 Virtual users are ramped down followed by the next 25 after a delay of 5 seconds, till all 100 users are removed from the site.

Time Mode Ramp-Down Phase

All Virtual users are removed from the system after a time delay (in HH:MM: SS). This Time Mode Ramp-Down can be done in any of the two ways:

• Time Mode Ramp-down – Linearly

All Virtual users are removed from the system after inserting the time delay of (HH:MM: SS) in a Linear mode. The system decides to pick a fixed number of users to Ramp-down. For example, the System decides to Ramp-down 20 users after every 5 seconds and so on till all 100 users are ramped-down.

• Time Mode Ramp-down – Randomly

All Virtual users are removed from the system after inserting the time delay of (HH:MM:SS) in a Random mode. The system decides to pick a fixed number of users to Ramp-down. For example, the System decides to Ramp-down 20 users after every 5 seconds, followed by 10 users in the next 5 seconds followed by 30 users ramped down in the next 5 seconds, and so on till all 100 users are ramped down.