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
  • Where are the ports used by HyperTest?
  • What are "Primary" and "Candidate" versions?
  • Why do I need two different versions of my application deployed?
  • Do I have to HyperTest run in a production environment? If not where does it run?
  • Is it required to have both versions connected to the same database?
  • Is using nginx absolutely necessary?
  • Why do the Primary and Candidate versions need to be in the same environment?
  • Why do the Primary and Candidate versions need to be connected to the same database?
  • Can HyperTest tell me how much of my application is covered?
  • Tests taking too long?
  1. FAQs

Setup

This page is mostly helpful for your Devops team or infra team.

Where are the ports used by HyperTest?

In the directory where HyperTest is installed, there is a ht-ports-info.json file that contains the 2 ports:

  • Logger Port: the port to which traffic is redirected

  • HT Port: HT Port is the Dashboard port.

Note : This is only applicable for Linux based setup


What are "Primary" and "Candidate" versions?

The terms "Primary" and "Candidate" refer to two instances of your application that are different in terms of code commits i.e. Primary version would contain the code that is in production while the candidate version will contain the code that is supposed to go into production.

Why do I need two different versions of my application deployed?

No, HyperTest works by performing a comparative analysis between the two versions of your application that are provided to it. Therefore, if identical application instances are provided to HyperTest, there won't be anything to compare.

Do I have to HyperTest run in a production environment? If not where does it run?

HyperTest does not need to be run in the production environment. The environment should be the one that receives the most traffic besides production will do. Just ensure that both the Primary and Candidate are in the same environment.

Is it required to have both versions connected to the same database?

As of the time of this writing, it is absolutely necessary for both the applications to be connected to the same database.

Is using nginx absolutely necessary?

No, any of the mirroring method will suffice, along with any other method that can redirect traffic to HyperTest.

Why do the Primary and Candidate versions need to be in the same environment?

Having both instances in the same environment ensures that there are no differences on responses that are caused by different environment variables.

Why do the Primary and Candidate versions need to be connected to the same database?

Using the same database ensures that both the application instances receive the same requests.

Can HyperTest tell me how much of my application is covered?

Amount of coverage is unique to every test because the traffic varies. The amount of APIs covered can be found on the API coverage button while starting a new test, as well as within the test on the dashboard. However, to enable this feature you need to provide with OAS_DOC_PATH configuration parameter.

Tests taking too long?

If your tests have a lot of requests in them, it is a good idea to increase the number of request runners via the "MAX_RUNNER_INSTANCES" parameter under "Configuration".

PreviousFAQsNextGeneral

Last updated 2 years ago