Performance Testing

• Easy-to-use web-based user interface to automatically record and playback websites using HTTP/HTTPS/SSL/AJAX requests in any Web browser.
• Automatically handles HTTP/HTTPS cookies, redirects, basic and digest authentication.
• Ability to test web servers that use compressed server response (gzip, deflate).

• Intuitive and easy-to-use Load Test Configurator UI allows you to configure multiple user scenarios to emulate the real-user activities. For example, you have the flexibility to split the number of users accessing different parts of the web application performing different operations, such as, 60% of users logging in - viewing books available - logging out, 20% of users logging in - adding to shopping cart - logging out and another 20% of users logging in - viewing price details - logging out of the transaction.
• Provides extensive configuration options to emulate multiple types of browsers, user behavior such as think times, repeat delay (user iterations), load percentage for each user, the speed with which the recorded business cases are replayed (normal with think time or fast mode), etc.
• Quickly change the server host (or test server) in the user profile configuration to run the same user scenario (recorded URLs) against different test servers without re-recording the test scripts.

• Accurately simulate a large number of virtual users performing a defined set of transactions (or business cases) in your web application.
• Group the individual user scenarios as user profiles and associate each user profile with different workload configuration (normal, ramp-up, ramp-down or burn-in) as load test cases to capture the real-life user testing.
• Configure various workload types to test your web site under different load and stress conditions. This includes:
  • Load Test (Normal Workload) - This test measures the capability of your web site under anticipated production workload. It runs the load test for a constant number of virtual users (steady-state workload) until the given test duration time has passed.
    
• Peak Tests (Ramp-up and Ramp-down Workload) - Ramp-up test determines the peak load at which your web site fails to respond. It simulates heavy load by gradually increasing the number of users at defined periods until the count reaches the maximum number of users. Ramp-down test determines the limitations of your web site when the load is gradually dropped off at defined periods from a peak value to a lowest value. You can create load test cases with ramp-up and ramp-down to compare and determine how well your web site responds at peak hours of the system and when it goes back to an idle state.
• Burn-In Tests (Burn-in Workload) - This test helps you to identify issues in your web site when a heavy load is hit for an extended period of time. You can exit the test only based on the specified exit criteria.
• Get a preview of your configured user profiles, workload details, server monitors and database monitors by clicking the Test case tab in the Load Test Configuration screen.
• QEngine provides the View Graph option to automatically generate the workload pattern graph (user count vs time) for each configured workload. This helps you to visualize how the load is generated against the server before running your load test and tweak the workload configurations to perform the desired performance test.

• Real-time session tracking to test web sites using session identifiers (cookies or URL rewrite).
• Parameterize the appropriate session IDs or request parameters in the recorded URLs to dynamically replace the test data. It replaces any parameter passed between the web browser and the server using character strings, dynamic data - from a Cookie Set in the response header, from element attribute in hidden HTML elements, from a previous response body, from a cookie or a parameter value by executing Javascripts or from a previous URL or from an external data source such as FLAT file or database. Parameters that can be replaced with dynamic data include: Session IDs, username/password pairs, URL parameters, form fields and any request parameter. For example, you can parameterize the username and password parameters in a URL to generate login/password pairs for each virtual user. This enables you to capture real-world user testing and effortlessly generate complex data-driven load test scripts in minutes.
• Ability to view a wide range of information using the Parameterization UI, such as Request Header, Response Header, Cookies, Parameters, and the URLs in a web page.
• Parameterization done for session IDs or requests parameters in one URL can be re-used for other similar URLs in the same business case using the Per BC Configuration option.

When users accessing your web site report a problem, you need to identify the source of the problem: it could be in the network, or it could lie with a database or the web server. To monitor all the key elements that drive your entire web application infrastructure, you need to have specific monitors to collect data from your web servers or databases. QEngine monitors critical web server parameters and database parameters for MySQL and Oracle databases. This provides better visibility into the performance of your web servers and databases that form the core components of your web application.

• Configure server monitors to monitor the resource utilization such as, CPU and memory usage of your web servers.
• Define monitors in Windows or Linux machines to collect data from web servers or databases running in local or remote machines. QEngine uses WMI to monitor server resources running in remote Windows machines and Telnet/CLI to monitor server resources in Linux machines.
• Configure MySQL or Oracle monitors to collect the database parameters specific to a database. Parameters collected for MySQL include:
  • Thread Details - Threads connected, created, running, cached, etc.
  • Connection Details - Max_used_connections, Aborted clients, Aborted connections, etc.
  • Temporary Table Details - Created_tmp_disk_tables and Created_tmp_tables.
  • Throughput Details - Bytes_received and Bytes_sent.
  • Query Details - Total Number of reads, Total Number of writes, Slow_queries, etc,
  • Table Related Statistics - Table_locks_waited, Open_tables, etc.

• Bandwidth simulation can emulate the different connection speeds with which the user connects to your web site. Each virtual user can be connected to the server with different bandwidths using a variety of modems, such as, Analog modem (14.4 kbps, 28.8 kbps, and 56 kbps), ISDN modem (64 kbps), Dual ISDN modem (128 kbps), and DSL modem (512 kbps).
• This feature is important as users accessing your web server with different bandwidths do not impact the web server in the same way. For example, different bandwidth users add an overhead on IO buffering and how long the sockets are kept open, etc. which will have a more significant impact on how your web server is optimized. For each user profile you can configure users with different bandwidth, where 60% of the users are connecting at 64kbps modem speed and 40% of the users are connecting at 28.8 kbps, etc.

• Insert built-in functions in the load test scripts to parse and validate the response contents and detect application-level failure.
• Validate response to verify the given element type, search text, status code or title exists in the response content. Adding response verifications in the load test scripts helps you to increase test coverage.

• Provides considerable flexibility, enabling testers to configure a wide range of options using the Settings tab that affect the playback of load test scripts. All these configurations are optional.

  • Configure think time multiplication factor to multiply the default time taken to record an action in a web page with the specified value. This is useful in performing real-world testing where each user spends thinking time (wait time) before performing the next action in the web page.
  • Users accessing a web page will not wait too long for a page to download. The delay may be due to error in socket connection or server not able to process the request due to some errors. To shorten this delay, you can configure socket timeout value, follow redirects, retries or retry delay for loading the web page.
  • Select connection type to the server as direct or using proxy. To send requests through a proxy, choose use proxy and configure the proxy authentication details.
  • Provides options to save the response details. All options are disabled by default. This includes:
    
    • Option to place image requests to download images.
    • Option to save the web page obtained in the response for all the pages. Enabling this option consumes a lot of disk space.
    • Option to give the list of response status codes to be treated as success codes to identify connection failures and automatically display the response status distribution graph in the reports indicating the success and failure status of the URL.
    • Option to save the logs obtained during load test execution for each user.
    • Option to add multiple play engines to support distributed load testing.
    • Enable or disable Unique IP for each Virtual User in settings screen to emulate the behavior of different IP addresses accessing the web application.
    • Most web sites have specific authentication methods that allow each user to login to the site with a valid user name and password. QEngine by default supports Basic/Digest scheme for authentication. You can also add other custom authentication techniques such as NTML, Kerbos, etc.

• To simulate a very high load hitting your web site, you have the option of simulating the users in a single machine with a high configuration or distribute the load across multiple machines using the distributed playback option. QEngine provides a single load test controller that centrally manages, automatically generates and distributes the load across multiple play engines.
• Web-based Play Engine Configuration UI allows you to quickly and easily configure the distributed machine IPs and the maximum virtual users to be simulated in each machine (Windows or Linux machines).

• Run and check your load test scenario with a single user, regardless of any changes in workload configurations, using the Verify mode. This will help you to identify any issues in load test configurations before running it with the heavy load that your web application will experience in the real-world.
• Run your load test script with the configured workload to simply replay the recorded URLs and identify the performance bottlenecks in your web application.

• In addition to test automation of your web applications and web services, QEngine provides built-in issue tracking software that helps you to track product defects and manage product enhancement requests. It enables users to log in defects / requests from any geographic location and allows all the team members to access the tracking system from anywhere, anytime. Click here, to learn more.

• QEngine allows you to integrate any third-party Bug Tracking Systems to help you track bugs the way you are used to.