Create Scenario

To create a scenario, select the  icon as shown in below figure.

Figure 44: Create Scenario Icon

The Create Scenario window is displayed as shown in below figure.

Figure 45: Create Scenario Window

The scenario will be created under the selected project and sub project with auto generated scenario name in the following format.

Scenario_<Month>_<DD>_<HHMMSS>

For eg-Scenario_May_03_025917

Figure 46: Project and Sub Project

Scenario type are of following types which can be chosen as per user interest:

  • Design Script Manually
  • Import Scripts
  • Replay Access Logs
Figure 47: Scenario Type

Let us discuss them in details

Design Script Manually

In this scenario type, Script design is manually done using interactive UI to compose HTTP requests with different methods. To access this click the start icon  . The following page opens once you click the icon.

Figure 48: Scenario Configuration Window

The screen is divided into two parts:

  • Left Pane
  • Right Pane

Left Pane

Figure 49: Left Pane

Edit Scenario Name

Whenever scenario is created by default its name will be of following format: 

“Scenario_Month_Day_HHMMSS”

For ex: “Scenario_Nov_08_011948”.

You can rename it by clicking the  icon.

Menu

Once you click the kebab menu , you have the following options as shown in the figure below:

Figure 50: Kebab Menu Option

The option are as follows:

  • Manage
  • Version Control
  • Select Scenario Profile
  • Download Scenario
  • Add Notes
  • Reset Settings

Note: In order to use these options, User need to save the scenario once.

Let us discuss the above in details

Manage

The manage consists of followings options:

  1. Copy Scenario

On clicking copy entire scenario directory and file related to it will be copied. When user clicks on the Copy option, following dialog will open where user can give copy name with project and sub-project of the scenario to copy.

Figure 51: Copy Option
Figure 52: Copy Scenario Dialog Box

Now, select the project and sub-project to which scenario needs to be copied. By default, default project and sub-project will be selected and scenario will also be prefilled with “Copy_” prepended to scenario name. Specify the scenario name in the Copy To section, and click the Next button. We get a successful message at the top right corner.

2. Move

We use this option to move scenario to different project. To access this select Move from the drop down of Manage as shown in Figure 51. Select the project and sub project to be moved and select the Save option.

Figure 53: Move Scenario

3. Save as Scenario Profile

We use this option to save the scenario as profile. To access this select Save Scenario as Profile from the drop down of Manage as shown in Figure 51. Select the project and sub project to be saved and select the Save option.

Figure 54: Save Scenario as Profile

4. Delete Scenario

On clicking “Delete”, a confirm pop-up will ask the user for confirmation to delete the scenario upon which the scenario will be deleted.

Figure 55: Delete Option Selection
Figure 56: Delete Confirmation

Version Control

Here, the user can view the version logs of a record. If there is a change in scenario, such as changes in API configuration, changes in Load configuration etc., then these changes are reflected in UI in the form of a modified file. If user has GIT configured, then he will see GIT History and GIT Commit else he will see Cavisson Version System options. 

There are two option in Version Control:

  • GIT History
  • GIT Commit

Let us discuss them in details.

  • GIT History

User can view the version logs of a Scenario through GIT history. Once user click GIT history in Version Control, the following page opens.

Figure 57: GIT history

In GIT history there are two GIT options:

  • Show Logs: It shows the version log of a scenario. You have the following columns in show logs:
  • Date time: Shows the date and time of the log.
  • Author: The owner of the file/logs.
  • Comments: Any comment made by owner is mentioned here.
  • Show Modified Files: It shows the files modified in scenario.
Figure 58: Show Modified List

It has the following columns:

  • File: Shows the files which are modified.
  • Status: Shows the status whether the files are modified or not.

In Git History user can perform below 2 actions:

  • Diff: Shows the changes between new and old version of modified files/logs.
  • Revert: If user want to revert back to older file/logs without the changes.
  • GIT Commit: This is used to commit the changes to a local repository. To access this, click the GIT Commit option in Version Control. A new dialog box opens as shown in below figure.
Figure 59: GIT commit dialog box
Figure 60: GIT commit successfully completed message

The user needs to provide the comments and click the Commit button.

Select Scenario Profile

On clicking Select Scenario Profile, user will be able to apply any scenario profile that is available in current workspace to the current scenario.

Download Scenario

On clicking download scenario, scenario folder along with scenario.conf will be downloaded as a tar file. Select Download Scenario option from the Kebab Menu as shown in below figure.

Figure 61: Download Scenario

Once this option is clicked, the scenario starts to download.

Add Notes

Add notes will allow the user to give some notes regarding the current scenario. These notes will be saved inside the scenario. Once you click the Add Notes in Kebab Menu the following dialog box appears.

Figure 62: Add Notes

Reset Settings

Reset settings allow the user to sync the current scenario with the server. If a new scenario is being created, then it will reset to new scenario or default values.

Tags

Tags are useful for user to uniquely identify scenario from test run UI. User can filter scenarios based on tags. Tags can be anything that user wants to associate current scenario with. For example, SpikeTest, ProductionTest, DataGen, etc.

Figure 63: Tags

Number of user

It tells the total users applied in this scenario in case of Fixed Concurrent Users Scenario, total sessions per minute in case of Fixed Session Rate Scenario and Quantity in case of Mixed Mode Scenario.

Duration

Duration is the total duration of scenario. It will be the sum of multiple duration phase if multiple duration phases are applied.

Location

On clicking Add Location user can add/edit generators to apply in the current scenario.

Figure 64:User, Duration & Location

Save & Debug

It will save the scenario and execute a debug test with 1 iteration per scenario group and apply below settings:

Tracing, Drill Down and Continue on page error enabled. Inline Resources Disabled. Use all HTTP headers as per scenario.

Note: The debug Test Run will open in a new tab from top menu.

Save and Run

It will save the scenario and execute a test with applied load configuration settings. On test execution a new tab is added in top menu where that Test Run details is shown.

Save

It will save the changes in scenario. 

Figure 65: Save Option

Right Pane

The right pane consists of three tabs:

  • Design
  • Test Run
  • Schedules
Design

Design tab is the landing page of the scenario. It facilitates scenario creation. Users can here add multiple groups with Cavisson API scripts, postman scripts, Cavisson scripts etc in API Configuration and also schedule the scenario in Load Configuration.

Figure 66: Design Tab

API Configuration

In API Configuration, the user can add a URL and its type like GET, PUT, POST, DELETE, PATCH, OPTION, HEAD, CONNECT and TRACE and add it to the request list table.

If a user wants to add additional information like Headers, Parameters, etc. then they can click on Additional Information and can add it. They can also add think time between pages by clicking on add Think Time. Users can add multiple requests in a group and a minimum of 1 group is mandatory.

In API configuration, there are two options such as design and script.

Figure 67: API Config Option

Design

When design is selected then the user can use UI to create/modify API groups.

Design have following fields:

  • Left Pane/Request List
  • Right Pane

Let us discuss them in detail.

Left Pane/Request List

In the request list, users can add Thinktime, Requests and Groups. Thinktime can only be added between two requests. Requests can also only be added inside a group. Users can also change the order of groups and request. Requests can only be moved inside a group.

By default, group name will be as follows:

            Group_{number_of_groups}

Users can edit the group, and the group name will be unique. Following is the screenshot of group inputs:

Figure 68: Group Input Page
  • In group, User can perform Clone and delete actions from kebab menu icon like below figure:
Figure 69: Group Menu Icon
  • Clone will duplicate the group. This group name is preceded by “Copy_”. For e. If the group name is “Group_1” then the cloned group will be “Copy_Group_1”.
  • Delete will delete the group from the request list.

Users can add a group by clicking the add group icon as shown in below figure.

Figure 70: Add Group

On clicking, add icon following dialog will open for user to add group:

Figure 71: Add Group

Users have following two options to add a group: ‘Design Script Manually’ and ‘Import Scripts’.

In Design Script Manually, a user can design an API group where he/she can add multiple groups where each group can have multiple requests.

In Import scripts, users can import an existing API script or select an already created script from current workspace or import postman scripts.

In this, we have pre-defined scripts which are: Cavisson Scripts and Postman Scripts.

  • Cavisson Scripts are those scripts that are created by Cavisson tools.
  • Postman Scripts are those scripts that are created from Postman.

Users can select their preferences by either Uploading a Script from the desktop or can Select from the System. For details of Import script refer to Import Script.

Group Settings

From here users can apply settings based on individual groups as well as for all group. By default, All Groups is selected. To apply settings group based click on  icon as shown in below figure:

Figure 72: Group Settings Icon

For details of Group Settings refer to Group Settings section.

Right Pane in API Configuration

The details in right pane depends on the option selected under request list i.e.,

  • Group
  • Request
  • Thinktime

Let us discuss in details options we get when we select these options.

  • Group

Users can rename the group add/edit users, parameters and assertions for API groups. Following is the screenshot:

Figure 73: Manage Parameter

Users can edit the group name, give the number of users. On clicking Manage Parameters, parameters UI will display where list of all parameters and assertion will be shown.

Figure 74: Add Parameter/Assertions

Here user can delete parameters/assertions or add more parameters/assertions. On clicking “Add Parameters” and “Add Assertions”, parameters and assertions UI will open  respectively in the sidebar. For more on parameters and assertions refer to Script User Manual.

In Cavisson group, when user selects group following UI opens in right side of API Configuration UI:

Figure 75: Group Edition

Request User can add request in API group by clicking  button at bottom of “Requests List”. Request is the url which will be hit when test runs. In request, user can give inputs like request/transaction name, method type, headers, body etc.

After adding request user can edit it by clicking on Request. On adding or updating request, following UI will open on right side of API configuration:

Figure 76: Request Details

Here user can select method type from drop down, enter the url and request name will auto generate according to URL. User can also change the request name. User can also add headers and request body along with request by clicking on “Show additional Info”. Requests will be added automatically when a user enters the url.

When user clicks on additional Info then following UI will display at bottom of “Request” screen as shown in below figure:

Figure 77: Additional Info

In additional info, the user can provide headers and body for request. In header, following headers are auto generated and hence won’t be shown by default. On clicking “Show Auto generated headers” following headers is shown:

Figure 78: Auto Generated Headers

Auto generated headers are disabled by default. User can also provide headers in text format for bulk headers at once. User need to click on the “Key-Value/Text” switch. On clicking following editor opens for user to edit headers:

Figure 79: Key Value/Text

User can provide body in editor where data can be given in text, json, xml, html, js, x-www-form-urlencoded and form data. The request body can be passed in the following format:

  • Text: In this format, the request body is sent in the form of text.
  • JSON: In this format, the request body is sent in the form of JSON.
  • HTML: In this format, the request body is sent in the form of HTML.
  • JavaScript: In this format, the request body is sent in the form of JavaScript.
  • XML: In this format, the request body is sent in the form of XML.
  • Form Data: In this format, the request body is sent in the form of either Text or File. In Text, the user can send the body in text form, and in the file, the user has to select a file from their desktop.
  • URL Encoded Form: It is the format in which the data will be passed to the server.

Following is the screenshot for body:

Figure 80: Body

User can also upload a body from any file in the desktop by clicking on the Upload icon. After filling all required fields, users can add it to the request list. All the data given by the user for a single request will be maintained in the data structure mentioned in the starting of “API Group”.

 

Think time: Think time is the delay between two steps/pages in the script. Think time passed in the API is called recorded think time. A think time can only be added after any request. For details of Think time refer to Think Time section.

Script

When script is selected then script of selected Cavisson Script group will be shown in textual view mode. User can select different flow files from the ‘Select Flow File’ drop down to view its content.

Figure 81: API Configuration(Script)

NOTE: Only flows of script will be available for viewing in script mode.

Load Configuration

Load Configuration displays the schedule graph and scheduling table. It also displays the group table. This section helps the user to schedule the scenario as per his/her need. Following is the screenshot of “Load Configuration”:

Figure 82: Load Configuration

Users can schedule load according to their needs.

  1. Basic
  2. Advance

BASIC 

  • Scenario Type: In load configuration users can choose the scenario type (FCU/FSR), edit group data and schedule scenarios. There are following scenario type among which user can select:
  • Fixed Concurrent Users (FCU): In this user defines the number of users for scenario.
  • Fixed Session Rate (FSR): In this user defines number of sessions for scenario.
  • Total number of users: Shows the total number of VUser in case of FCU scenario and Sessions/Minute in case of FSR Scenario.
  • Schedule by: Users can schedule by either scenario or group. In scenario “Schedule By”, scheduling is applicable to the entire scenario. But in group based scheduling, scheduling will be applied group wise. Following is the screenshot of scheduling graph in group by scheduling:
Figure 83: Schedule by Group Graph
  • Distribute Mode: User can distribute number of users or session rate by giving number of users or percentage. In the case of percentage, the user is given the total number of users in the “Total Number of Users” field and can provide a percentage for each group.
  • Optional columns can be selected by the user from the “Show Columns” drop down above the group table.
  • Group Details: In group details, there are the following fields:
Figure 84: Group Details
  • Group Name: It displays the name of the group.
  • Scenario Type: It describes the type of scenario used in the test.
  • Session/minute (only in case of FSR):It describes the session per minute.
  • Users (only in case of FCU): It describes the total number of Vusers.
  • Actions: It is used for performing 2 types of actions in a group i.e.: Edit and Delete.
  • Edit: It is used for editing an existing group.
  • Delete: It is used for deleting an existing group.
  • If the group being edited is an API group, then only the group name and number of users can be edited from there. If it is cavisson group, then user can edit all the inputs that come in cavisson group.
  • In the Load Configuration section, user can specify the duration like, ramp up, stabilize, Duration/iteration and ramp down time. Based on configuration settings, the information graph is displayed in the right panel, as shown highlighted in the following figure.
Figure 85: Basic Scheduling
  • Ramp up: It is the amount of time to add all virtual users to the load test. Users can ramp up time in hours(s), minutes(m) and second(s).
  • Stabilize: Stabilize is same as duration phase but it is not included in the report. Stabilization should be in hours, minutes, and seconds. Input fields should only contain h, m, or s respectively.
  • Duration: Duration represents the runtime of the test. Duration should be in hours, minutes or seconds.
  • Iteration: Iteration defines the complete end to end journey of the user mentioned in the groups. It is the collection of requests. User can specify either total iteration count or iteration count per user.
  • Ramp Down: It is the amount of time in which all virtual users exit from the load test. User can ramp down time in hours(h), minutes(m) and seconds(s).
  • Schedule Graph: Schedule graph on the right will update when the user changes any of the phase time.

Advance

If a user wants to customize phases, he can switch to Advance settings for Load configuration. Following is the screenshot for advance scheduling:

Figure 86: Advance Scheduling

In advance scheduling by default there will be 5 phases (Start, Ramp up, Stabilize, Duration and Ramp down). User can add/modify phases as per requirement. 

Phase can be added from “Add Phase” button or context menu in Actions column:

Figure 87: Add Phase

If the user adds phase from the “Add Phase” button, then phase will be added at last and if user adds phase from the context menu then phase will be added after the selected phase.

On clicking Add phase following dialog will open:

Figure 88: Add Phase( Ramp Up)

Users can select the type of phase the user wants to add from the “Phase Type” drop down. On changing “Phase Type” the content will change according to the selected phase.

  1. Start Phase

The Start phase signifies the time duration of starting operation.

Figure 89: Start Phase

The following actions can be configured in the Start phase:

  • Assign a proper name to the Start phase. For example:
  • Start type can be either Immediately after the Scenario begins or specify time in following format (HH:MM:SS) after which the scenario starts.

 

  1. Ramp-up

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. Refer to Figure 88.

  1. 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 90: Add Phase- Ramp Down

Ramp-Down can be done by 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.

  • By user and time 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 next 25 after a delay of 5 seconds, until all 100 users are removed from the site.

  • Time Mode Ramp-Down Phase: All Virtual users are removed from system after a time delay (in HH:MM:SS). This Time Mode Ramp-Down can be done by any of the two ways:
    • 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-down. For example, 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 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. For example, System decides to Ramp-down 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.

 

  1. 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 91: Add Phase-Duration Phase

This Duration phase can be further achieved by following 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.

  • Indefinite Mode Duration Phase

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

 

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 92: Add Phase-Stabilization Phase

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

In advance settings as the user adds phases the schedule graph will update. If user adds phases such that scheduling is invalid, then user will be shown error. For example, user tries to add “Ramp Up” phase with more than number of users defined in scenario:

Figure 93: Add Phase Error

In advance with FSR and FCU we have an additional Scenario type of Mixed mode. In this user can choose group which can be either FCU or FSR.

 

 

Additional Settings

Additional settings (Formerly called Global Settings) can be accessed from bottom of the load configuration as shown in below figure. These settings are applicable in entire scenario.

Figure 94: Additional Settings

For details in additional settings refer to Additional Settings section.

Test Runs

This tab will show all the test run executed for current scenario.  Following is the screenshot for same:

Figure 95: Test Runs

The user can launch a web dashboard from the Test Run table found in the test run tab. In addition to the capability of locking, deleting, etc., the user can also filter and search Test Run.

Test Run(TR) table consists of following columns:

  • Checkbox( ): With help of checkbox user will be able to delete, archive, lock, compare multiple Test Runs at one go.
  • Status: determines the status of Test Run. Following can be the status of a Test Run at a time:
  • Running : Shows that  Test run is in execution mode.
  • Completed : Once a test run has been running for a certain amount of time, it is deemed finished. because a test can be stopped midway after it has started running.
  • Passed : The rules in a checkprofile that the user has applied will decide the status of a Test R Test runs are deemed successful if they meet certain requirements or regulations.
  • Failed : When test run failed to execute or test run failed to satisfy conditions or rules defined in checkprofile, then it is considered to be failed.
  • Test Run: The unique Test Run number that Load Test provides automatically to a Test run.
  • Test Name: The test name user can give to a test.
  • Start Time: The time when test is actually started.
  • Run Time: This is the total duration for which the test executes.
  • Users: The number of users defined in the scenario which is being executed i.e. the number of users simulating in the test run.
  • Tags: These are the tags defined in the scenario which are used to filter out test run based on applied tags.
  • Actions: Following are the actions performed in test run:
  • Delete( ): This deletes the Test R User is asked for confirmation before deleting Test Run.
  • Open Dashboard( ): It opens the dashboard of a particular Test R
  • Open Transaction( ): If test is initialized properly,  it will open transaction detail UI in a new tab. else it will open test initialization screen in a new tab.
  • Kebab Menu: It has the following g fields:
Figure 96: Menu Icon(Action)
  • Archive: This will archive/unarchive the selected TR. User will get a confirmation message whether he wants to archive or not.
  • Lock: Locks/unlocks a particular TR.
  • Test Initialization Screen: Clicking this will open the initialization screen for the TR. Test Initialization Status window that displays the different stages of the test initialization for both controller and generators.
Figure 97: Test Initialization Status Page

On the right panel, the window also displays information like User, Start Date Time, Duration, Scenario Type, Warning Count, Test Initialization Elapsed Time, and Test completion pie chart. 

  • Test Status Report: This will open the test status report where the user can check the periodically generated report or overall report for the applied checkprofile in scenario.
  • Export test: Export the tar of the test run to the user’s desktop. Users will be asked to select the contents of TR that will be exported. Test run scripts, Server logs, drilldown data, Request-Response files, and event logs are the contents of TR which the user have the option to select from. User can also select all components to export.
Figure 98: Export Test Run
  • Open Pagedump: It redirects to pagedump UI as shown in below figure.
Figure 99: Page Dump UI

In page dump, there are following columns:

  • Start Time: Shows the time when this page executes.
  • Page Name: Name of the page which is executed.
  • Page Status: Shows status of page, whether success or failure.
  • Page Response time: Time taken to load the page.
  • Parameter Substitution: Applied parameters with their value.
  • Req: Shows header and body of request.
  • RepBody: Shows body of the response.
  • Rep: Shows the header and body of the response.

Open Transaction summary report: Redirects to transaction summary report. This report should display Transaction summary, such as transaction name, minimum duration, average duration, maximum duration, median duration, 8th percentile, 90th percentile, 95th percentile, 99th percentile, script count, number of tries, success, fails attempts, and fail percentage

Figure 100: Transaction Summary Report

Following actions can be applied over multiple testruns:

  • Global Search Bar

The user has the option of searching for TR using tags, test run numbers, test status, start times, run times, and test names. When conducting a search, only the TRs that are already in the table will be considered. If the user applies filters before conducting a search, the search will only consider the filtered TRs.

Search & Filter( ): On clicking this option, it enables column filtering. User can filter test runs column wise.

  • Delete( ): On clicking delete button, it will delete all selected TR’s from server. If no TR is selected, then validation error will be displayed.
  • Archive Test Runs( ): This archive/unarchive all the selected TR’s. If no TR is selected, then validation message will be displayed.
  • Lock Test Runs( ): This lock/unlock all the selected TR’s. If no TR is selected, then validation message will be displayed.
  • Download Table: Complete Test Run table will be downloaded. User need to selected download format which can be word, excel or PDF.

 

Schedule Test

Schedule test allows users to schedule test execution for the current scenario. The test is completed on the basis of pre-condition inputs and scheduled time.  Scheduler will allow user to schedule test execution for current scenario. It has the following columns:

  • Schedule Name:Shows the schedule name of the scenario.
  • Description: It is the description provided by the user at time of scheduling the test .
  • Schedule Time: The time when the test is to be executed.
  • Schedule Expiry time: The time when the scheduler needs to be stopped.
  • Status: Shows the status of the scheduled test.

Action: Provide the option to edit or delete the scheduled test.

Figure 101: Scheduler

The user can schedule the current scenario from here, and this page will display all of the scheduled tests for the current scenario. After selecting “Schedule Test,” the user is taken to the “Schedule Test” UI, where they need to enter their scheduling details.

The user can select the scheduling type from the options in the top right. The user can set daily, weekly, or monthly schedules. Tasks will be filled in the calendar.

Figure 102: Schedule Test

Schedule Settings Options

  • Schedule Name: Name of schedule or task that user wants to schedule.
  • Description: Here user can give some information about scheduling purpose.
  • Schedule Expiry time: This is mandatory field. User have to give an expiry time.
  • Mail Settings: User also need to give mail information like To, subject, body, etc to receive mail when scenario is scheduled.
  • Advanced settings: Here user can give how much time to wait if all controllers are busy i.e. there are already maximum number of test in running state.

Import Script

A Script represents a typical session of web application’s user interaction. We support Postman and Cavisson scripts.

Figure 103: Import Script in a Group

User have following two preferences:

  • Upload Postman Script
  • Browse Script from Server

Upload Postman Script

User can upload the postman collection (json file) from local machine. After upload, its converted to Cavisson API scripts and can be modified further as per user requirement.
Note:  User can upload Cavisson scripts from Script Manager.

Browse from Server

In this, User can choose any script available on their server. Once you click the Browse from Server button, the below figure appears.

Figure 104: Script Selection

Select script has the following fields:

  • Project/Sub Project (applicable, if script is from another project)- Project/Subproject are used for holding test assets like the script, scenario, test suite, and check profiles. They are folders/subfolders and can be managed from Project Administration Screen.
  • Script– Select the script which the user wants to include in the scenario.
  • 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.
  • Users: Assign a number of Virtual users to run the script.
  • Runlogic: RunLogic allows users to create a custom flow (sequence of pages) to be executed. If the script has multiple runlogic then user can change the default runlogic according to their need.
  • User Profile: The User Profile is User Location-based. An existing User Profile from the drop-down can be selected. The default is “Internet”.
  • Override data directory: If the user overrides the data directory, the data files of all file parameters are taken from the specified directory. If no file is found, it will be taken from the data directory specified in the file parameter and then from the script directory.

Note: By default, Script from the same project/sub-project is displayed. If the user wants the script from another project, then he has to enable the button from above.

Replay Access Log

Replay Access Log allows users to replay or re-run the scenario using the logs recorded in the Access Log File. All requested URLs’ logs, including requests, responses, Method types (Get/Post), HTTP Headers, Client IP, Remote IP-address, and JSESSIONID, are kept in Access Log Files. The Replay Access Log scenario lets you recreate the production scenario and the complete layer of faults by replaying the access logs produced during live traffic (which are not reproducible in Test environment). Use pre-captured Access Log to create the scenario. Access Log is a type of log that contains all requests to resources of a website.

Running a Replay Access Log

A Replay Access Log scenario enables you to analyze customer logs and simulate the real-time network scenario. You can also customize various settings to test different scenarios.

To recreate a scenario using the Replay Access Log follow below steps:

  1. Create a Replay Access Log scenario.
  2. Customize the Replay Access Logs settings.
  3. Process the Access Log File.
  4. Analyze the Processed Data.
  5. Run a Script and Compare Results.

To access Replay Access Log, go to create Scenario option and then select Replay Access Log as shown in below figure.

Figure 105: Replay Access Log Selection

Replay Access Log scenarios provide the flexibility to select one or more log files with filters, date/time selection, all or pieces of URL selections. You can also compare the performance test results of actual run on production environment and Replay run on Test environment on the dashboard based on the Test Run for better understanding of capacity utilization.

Once you click the Start button in Replay Log Access, following page opens.

Figure 106: Replay Access Log Page

Replay access log settings are changed according to log type It has five parts:

  • Replay Access Log Details
  • Replay Settings (only for HTTP)
  • Select Log Files (HTTP and SQL)
  • Add URL Filter (only for HTTP)
  • Add URL Pattern (only for HTTP)

Let us discuss them in details.

Replay Access Log Details

Figure 107: Replay Access Logs Details
  • If you click the settings icon , following page opens.
Figure 108: Schedule Advance Settings

It has the followings options:

  • Session Rate Pattern:
  • Constant Inter Arrival Pattern: Session rate will increase at a constant rate.
  • Poisson Random Inter Arrival Pattern: Session rate will increase at random rate.
  • Limit Maximum Users: Check this box to limit the maximum number of user.
  • Scenario Type:
  • Web Service: In web service, User has to give only Replay access log details with following fields:
    • Replay Directory
    • User Playback Factor
    • Users Arrival Time Factor
    • Inter Page Time Factor

Replay Iteration Count

Figure 109: Scenario Type- Web Service
  • HTTP Logs: It has following fields in Replay access log details:
    • Replay Profile
    • User Playback Factor
    • Users Arrival Time Factor
    • Inter Page Time Factor
    • Replay Iteration Count

Refer to Figure 107 for details in figure.

  • SQL Frequency List: It has only replay profile in Replay access log details.
Figure 110: Scenario Type: SQL Frequency List
  • Replay Profile: Enter replay profile name which will store all replay settings.
  • Replay Directory: Enter the name of the directory.
  • User Playback Factor: Specifies the percentage of users to be replayed. If it is 50%, then 50% of the users are replayed. 100% means all users are replayed. This value cannot exceed 100% because user cannot replay more than the allotted users.
  • Users Arrival Time Factor: Offers the flexibility to the user to change the arrival time according to their requirement. This specifies the time at which next user arrives. The Value should be given in percentage. By giving the Users arrival time factor, user can change the arrival time as:
  • Given as 25%, so next user hits in 2min30sec from first user.
  • Given as 100%, so next user hits at same time without any changes.
  • Given as 300%, so the next user hits in 10*3 i.e. 30min from first user.
  • Inter Page Time Factor: Offers the flexibility to a user to change the arrival time of different pages to their requirement. This specifies the time at which next page arrives.

Replay Iteration Count: enter the count of iteration to be run.

Replay Settings

Figure 111: Replay Settings

It has following fields:

  • Access Log type: The Access log file is of following type:
  • Apache
  • IIS
  • Weblogic
  • Custom
  • Create User Session: User Session can be created using following two ways:
  • Cookie: When User selects Cookie option for creating user session, user needs to provide the following values:
  • Primary Cookie Name. Default value is JSESSIONID.
  • Check box to Keep/Ignore URLs without Primary Cookie.
  • Check box to use/not use Secondary Cookie and its value in the text field.
  • Client IP: When user selects Client IP option for creating user session, user needs to provide the following values.
  • Check box to keep/ignore URLs without Client IP.
  • Check box to use/not use Secondary Cookie and its value in the text field.
  • Date/Time in access log: Date/time of access log is timestamp of either Request or Response.
  • Randomize replay time: Provide an option to user to set a wait time in milliseconds for multiple requests coming at the same time. User can set any time in milliseconds by putting a check mark on Randomize Replay Time.
  • Redirection handling mode: It has following two option:
  • Auto Mode-When script is created and test is fire then, URLs should be redirected to other URLs. Default value is 20.
  • As Per log– In this, URLs’ are not redirected to another URL and URLs are taken as per the Log file.
  • Ignore Query String: If Yes is selected, then in process Data table it should show the URLs records without Query String Parameter. In case of No, in process Data table it should show the URLs records with Query String Parameter after Question Mark.
  • Inline Object mode: Inline mode has following options:
  • Skip Inline: Shows only those URLs which are not inline.
  • Auto mode: In Group Based Setting Auto Fetch Embedded for All pages with option “Fetch every time” would be enabled.
  • Number of NVMs: Number of NVM to create replay data file. Users are distributed in such a manner that all NVM get users based on the start time. For example, if there are 100 users and 10 NVMs. Then each NVM gets 10 users.
  • Start Date/Time: This option enables the user to select data of a particular date and time interval to fetch and use as replay.
  • End Date/Time: User need to specify the end date and time till when data need to be fetched.
  • New User Time: It is the time selected by new user.

Select Log Files

Figure 112: Select Log Files

It has following fields:

  • Log Files: To browse for the log files click the available button. The following page opens:
Figure 113: File Manager Page
  • Current Directory: Path/directory where all the mentioned files are available.
  • Search Directories: Search directory from the available table.
  • Create Directory: Enter the folder name to create a new directory.
  • Name: Name of the file or the folder.
  • Date Modified: Date and time when the files are changed/modified.
  • Type: Shows the type of file.
  • Size(KB): The size of a particular file.

Click OK and then we have following details in table:

  • Log File Name: It is the name of the log file.
  • File Size(KB): Shows the file size in KB.
  • Request Count: Shows the count of the request.
  • File Type: Shows the type of given file.
  • Action: Used to update or delete a particular file.

Add URL Filter

Figure 114: Add URL Filter

It has following fields:                                          

  • Status: Shows whether URL is active or inactive.
  • Method: All the HTTP methods which the user needs to select as per the requirement.
  • Sample URL: Users need to mention the kind of URL pattern that he/she need to pattern.
  • Host: Name of the host.
  • URL Filter Pattern: User need to mention the filter URL pattern which they need to perform.

Add URL Pattern

Figure 115: Add URL Pattern

It has following fields:

  • Status: Shows whether the URL is active or inactive.
  • Type: URL type which can be main or inline.
  • Method: All the HTTP methods which the user needs to select as per the requirement.
  • Sample URL: Users need to mention the kind of URL pattern that he/she need to pattern.
  • URL Pattern: User need to mention the kind of URL pattern which they need to perform.
  • Transaction Name: This transaction name is auto filled in URL list file for all the matching URL.
  • Host Name: Place where request of a particular URL goes.
  • Comments: Comments can be used by user to give some comments about a pattern.
  • Body Request Files: This includes all the strings that are included in the body of our requested resource.
Previous
Next