QF-Test for UI-based Load Tests
This video shows you how you can create system load via the UI with the QF-Test Demo test suite for monitoring and measuring real end-to-end times as well as user acceptance times and ressources needed.
- The application is stressed/set under load. Many simultaneous/synchronized actions test the application’s load limit. QF‑Test’s special characteristic is that load tests are executed via the graphical interface (User/transaction via QF-Test in their own user sessions) and not evitablyprotocol based.
- The detection of non functional errors is possible: e.g. response time, simulated live operation, stability of server/client environment. Supplement to functional oriented tests.
- You can create load tests out of functional components (QF-Test is primarly a functional UI testing tool), so you can reuse existing steps.
- Checking the client’s side hardware dimensions is possible. Alternatives: via virtual computers/desktops, cloud based solutions, dockers/ containers.
- QF-Test can be combined with many other tools, so that load is generated: Tools like JMeter, JUnit as well as specialized load test tools like NeoLoad (a protocol based tool for web), Loadrunner from hp, Gatling, Silkperformer, Scapa TPP etc.
- Technical details and implementation of QF-Test load tests are documented in the manual. An easy scenario and example of implementation is delivered in the QF-Test installation.
- For the execution of load tests (also for higher numbers) cost-effective runtime licenses can be purchased or leased (subscription licensing) for a determined period of time.
Practical examples: QF-Test in use
Mrs Weiß of Münchener Verein, Munich, Germany: „When the cost-benefit-analysis in a project doesn’t recommend an extensive load tests, the existing QF-Test automted tests are started manually or time-controlled as a batch-job on 20 virtual machines at MÜNCHENER VEREIN insurance group. So that load is created on the application and a statement concerning performance is possible.”
Evaluation report for load tests: Comparison of 11 tools, opensource and commercial: Practical example of ALEA GmbH
Load tests with QF‑Test in the web area
Connection to highly specialised commercial tools:
- NeoLoad by Tricentis (former Neotys)
- Loadrunner by hp
- Silkperformer
- Scapa TP
As well as open source tools:
- JMeter
- Gatling
NeoLoad and QF‑Test
QF-Test’s focus is the web interface, NeoLoad’s focus are the Backend systems and network level.
- Regression tests created via QF-Test can still be used in NeoLoad as load tests, stress tests and performance tests.
- In the web area such tests are executed on network protocol level, this means without graphical presentation in the browser. NeoLoad converts these QF-Test regression tests into web load tests.
- Muth Partners has creaetd a special software interface to integrate existing QF-Test scripts.
Advantages of load tests with both tools
- These NeoLoad load tests contain a a metric of end user experience for new analysis possibilities.
- Automated import from QF-Test to NeoLoad to a great extend.
- Recognition possible via names of sequences and transactions
Further reading
- Whitepaper for NeoLoad
- Webinar recording
- Press release by QFS and Neotys
- Whitepaper about the integration of QF-Test in NeoLoad by Muthpartners
Check it out yourself
- Checklist to review your requirements and to compare QF‑Test with other automated testing tools
- Evaluation reports to look up
- Try for free with the trial license, fully functional, for 4 weeks
FAQ – Frequently Asked Questions about Performance and Load Testing
How often should automated performance tests run?
Ideally, small smoke-performance checks should run on every major build or merge.
How often should automated performance tests run?
Ideally, small smoke-performance checks should run on every major build or merge.
More extensive load and stability tests are usually scheduled nightly or before releases to ensure comparable results.
What minimum requirements should an automated performance test meet?
It should be reproducible, have a clearly defined load profile, and verify measurable target metrics (e.g., p95 latency, error rate).
What minimum requirements should an automated performance test meet?
It should be reproducible, have a clearly defined load profile, and verify measurable target metrics (e.g., p95 latency, error rate).
In addition, monitoring is needed so that the causes of deviations can be traced.
How should external dependencies (e.g., payment, login, APIs) be handled in automated tests?
They are either intentionally included as part of the end-to-end scenario or replaced in a controlled manner (mock/staging) to achieve stable results.
How should external dependencies (e.g., payment, login, APIs) be handled in automated tests?
They are either intentionally included as part of the end-to-end scenario or replaced in a controlled manner (mock/staging) to achieve stable results.
It is crucial to define a strategy for each dependency and make it transparent in the results.
How can “flaky” performance tests be prevented?
By using fixed test windows, stable test data, identical configurations, and repeated runs with median/percentile comparison.
How can “flaky” performance tests be prevented?
By using fixed test windows, stable test data, identical configurations, and repeated runs with median/percentile comparison.
Additionally, it helps to define thresholds with tolerances and avoid putting parallel load on the infrastructure during tests.
