Hypertest Docs
HyperTestKnowledge Base
  • Quick Set-up
    • Install HyperTest
    • Deploy your application
    • Mirror Traffic
      • Using Kubernetes
      • Using Amazon ECS
      • Using Docker
      • Using Nginx
      • Using Goreplay
        • ElasticBeanStalk Script for Goreplay
      • Using Apache
      • Using IIS
      • Using Istio
      • Using Kong
      • Using HAProxy
      • Others
  • HyperTest Overview
    • Introduction
    • Architecture
  • Detailed Setup Guide
    • Detailed Setup Guide
      • Installation
        • Linux VM
        • Kubernetes Cluster
          • Hardware Requirements
          • Cluster Setup
            • EKS
              • Existing Application Load Balancer
              • Calculate Setup Cost for EKS Cluster
            • GCP
            • AKS
            • Self Managed
              • Microk8s with EKS-D
          • HyperTest Installation
      • Mirror Traffic
      • Configure HyperTest
      • Automate Starting a Test
        • CI Integration
          • GitHub Checks Integration
            • Mandatory checks
          • Gitlab Integration
          • Bitbucket Integration
          • Jenkins Pipeline
            • Jenkins Plugins for PR events
  • Upgrade HyperTest
    • Upgrade HyperTest
      • Linux VM
      • Kubernetes Cluster
  • User Guides
    • Usage Guide
      • Install and Configure HyperTest
        • Install HyperTest
        • Configure Base DNS
        • Add New Service
      • Tests Runs and Analysis
        • View Test Cases
        • Start New Test Run
        • Understand Your Test Run Analysis
        • Prioritize Your Error Types
        • Track Bugs
        • Ignore Errors/Desired Changes
        • View/Download Report
        • View Consolidated Dashboard Reports
        • Sign-off Reports
        • Reduce Execution Time
        • Deduplication Rules
      • Troubleshooting and FAQs
    • Best Practices Guide
      • Cost Optimization
    • Dashboard Tour
      • Dashboard
      • All Sessions
      • Regression Report
      • Notifications
      • First Test Run
      • Interactions
      • Custom Analysis
      • Configuration
    • User Management
      • Create Admin User
      • Roles, Groups & Users
      • Enabling User Signup
    • Other Guides
      • Basic Nginx Auth for Linux HT
  • Middleware
  • Advanced Features
    • Import test cases from Postman
  • Change Log
  • Troubleshooting
  • FAQs
    • Setup
    • General
    • Regression Report
  • Glossary
    • Session
Powered by GitBook
On this page
  1. User Guides
  2. Usage Guide
  3. Tests Runs and Analysis

Reduce Execution Time

Eliminate duplicate or redundant requests/sessions from your test runs to reduce your test's runtime.

PreviousSign-off ReportsNextDeduplication Rules

Last updated 2 years ago

While starting a test you can choose to not run duplicate requests or sessions by selecting checkboxes: Deduplicate Requests and Deduplicate Sessions

You can check out the number of Sessions and Requests that are going to be played and how much time you will be saving with deduplication

When you choose to deduplicate Requests, HyperTest will only consider requests with unique parameters in a particular session. The latest requests are given preference when deduplicated.

In the case of deduplicating Sessions, HyperTest will weed out the duplicate session based on the scenarios they cover while taking requests with unique parameters into account.

For example, let's say you have 2 sessions(A and B), session A contains the Log in, Add to Cart, and Checkout scenarios, and on the other hand session B contains just the Login scenario with requests having the same payload as session A, we can say session B is a subset of session A, In this case, HyperTest will choose session A to test as it contains all the unique scenarios.

Advanced Request Deduplication

You can tell HyperTest what aspect of a request to consider while deduplication, by default unique request parameters are considered, but you can choose from other options according to your needs.

The options provided have a Level associated with them, the higher the level, the higher the reduction in the number of requests.

You can also provide the request deduplication level from CLI:

./hypertest start-new-test --req-dedup-level [numeric level value(1-3)]

If you're planning to use this feature in your CI pipeline, first make sure that you check test stats(Requests Count) from UI because using this feature will make your tests run fast but it can also make you miss logical errors, as it will reduce the number of requests you test by a significant amount.

Let's try to understand these options with an example, we will take a Session that contains some requests and we will see the result of deduplication with each option.

Results with each option:

Total request Count: 5

No.
Path
Payload
1

GET /api/v1/products/5

Query: {

"lang": "en"

}

2

GET /api/v1/products/6

Query: {

"lang": "en"

}

3

GET /api/v1/products/5

Query: {}

4

GET /api/v1/products/8

Query: {

"lang": "fe"

}

5

GET /api/v1/products/6

Query: {

"lang": "en"

}

Level - 1: Unique Request Parameters

The request Count is reduced to 4 from 5. In this scenario, only those requests are picked whose parameters were unique.

By default, HyperTest will consider these parameters: Path, Query, Body

No.
Path
Payload
Included In Test
1

GET /api/v1/products/5

Query: {

"lang": "en"

}

2

GET /api/v1/products/6

Query: {

"lang": "en"

}

3

GET /api/v1/products/5

Query: {}

4

GET /api/v1/products/8

Query: {

"lang": "fe"

}

5

GET /api/v1/products/6

Query: {

"lang": "en"

}

Level - 2: Unique Request Schema

Result when deduplicating with unique request schema:

The request Count is reduced to 2 from 5. In this scenario, only the latest requests were picked which had unique payload schema, request parameter names are considered not their values.

No.
Path
Payload
Schema
Included In Test
1

GET /api/v1/products/5

Query: {

"lang": "en"

}

Schema: {

path:

"/api/v1/products/{id}",

query: ["lang"]

}

2

GET /api/v1/products/6

Query: {

"lang": "en"

}

Schema: {

path: "/api/v1/products/{id}",

query: ["lang"]

}

3

GET /api/v1/products/5

Query: {}

Schema: {

path: "/api/v1/products/{id}",

query: []

}

4

GET /api/v1/products/8

Query: {

"lang": "fe"

}

Schema: {

path:

"/api/v1/products/{id}",

query: ["lang"]

}

5

GET /api/v1/products/6

Query: {

"lang": "en"

}

Schema: {

path:

"/api/v1/products/{id}",

query: ["lang"]

}

Level - 3: Unique Request Path

Result when deduplicating with the unique request path:

The request Count is reduced to 1 from 5. In this scenario, only the latest requests were picked which had a unique path, payload and parameters are not being considered.

No.
Path With Param Value
Path
Payload
Included In Test
1

GET /api/v1/products/5

GET /api/v1/products/{id}

Query: {

"lang": "en"

}

2

GET /api/v1/products/6

GET /api/v1/products/{id}

Query: {

"lang": "en"

}

3

GET /api/v1/products/5

GET /api/v1/products/{id}

Query: {}

4

GET /api/v1/products/8

GET /api/v1/products/{id}

Query: {

"lang": "fe"

}

5

GET /api/v1/products/6

GET /api/v1/products/{id}

Query: {

"lang": "en"

}

Now that you have understood what deduplication is let's look into what a is and how to create it.

deduplication rule