With the 2026 Q1 release, LoadGen introduces the new LoadGen FunctionalEngine executable for running functional tests outside of Studio. In earlier versions, it was often necessary to run functional tests from an elevated Studio session. Starting from this release, the FunctionalEngine provides a separate execution component that can be started either elevated or in a normal user context, depending on your environment and the type of test you want to run.
This makes functional test execution more flexible, easier to automate, and better suited for scheduled tasks, service-based execution, and troubleshooting scenarios.
Why use LoadGen FunctionalEngine
The FunctionalEngine is designed for headless execution of functional tests. It allows you to:
- Run a functional test without opening Studio
- Execute tests from the command line
- Integrate functional execution into scripts, schedulers, or pipelines
- Choose between interactive project selection or direct execution
- Run WebTesting in headless or visible browser mode
- Execute tests in either standard user or elevated administrator context
This is especially useful when:
- Studio does not need to be opened on the test machine
- you want to run tests through Windows Task Scheduler
- you need to troubleshoot execution differences between elevated and non-elevated sessions
- you want a cleaner separation between test design and test execution
Executable location
The new executable is:
LoadGen.FunctionalEngine.exe
The configuration file is stored at:
C:\Program Files\LoadGen\LoadGen FunctionalEngine\FunctionalEngineConfig.xml
If this file does not yet exist, it will be created automatically with default values when the FunctionalEngine is started.
Basic usage
LoadGen.FunctionalEngine.exe [options]
You must choose one input mode when running a test.
Input modes
Automation file mode
Use an automation XML file generated by Studio.
--automation <path> -a <path>
Example:
LoadGen.FunctionalEngine.exe --automation "C:\Tests\test.xml"
In this mode, the automation XML defines the project, repository, output path, and other settings. If values are present in the XML, they take precedence over command line defaults.
Project mode
Run a specific project directly from the repository database.
--project <name> -p <name>
Example:
LoadGen.FunctionalEngine.exe --project "Login Test"
This executes the project called Login Test from the configured repository database.
Interactive mode
Launch the engine in interactive mode so you can select a project from a menu.
--interactive -i
Example:
LoadGen.FunctionalEngine.exe --interactive
If no arguments are provided, the engine will also try to start in interactive mode when a terminal is available.
No arguments
LoadGen.FunctionalEngine.exe
Behavior:
- If running in a terminal, the engine starts in interactive mode
- If output is piped or interactive mode is not possible, it lists the available projects
Discovery and configuration commands
List projects
Use this option to display all available projects and testcase details.
--list-projects -l
Example:
LoadGen.FunctionalEngine.exe --list-projects
This is useful to verify:
- that the repository database is found correctly
- that the project exists
- how many testcases are included
Configuration commands
These commands update the default configuration and then exit.
Configure repository database
--configure-repository <path>
Example:
LoadGen.FunctionalEngine.exe --configure-repository "C:\LoadGen\Repository.db"
This sets the default repository database path in the FunctionalEngine configuration file.
Configure results database
--configure-results <path>
Example:
LoadGen.FunctionalEngine.exe --configure-results "C:\LoadGen\Results.db"
If the results database does not yet exist, the required tables will be created automatically.
Database options
Repository database path
--repository-db <path>
This specifies the repository database that contains the functional projects.
Example:
LoadGen.FunctionalEngine.exe --project "Login Test" --repository-db "C:\LoadGen\Repository.db"
Notes:
- if omitted, the engine will try to auto-discover the repository in common locations
- if an automation XML file is used, the repository setting inside the XML overrides this parameter
Result database path
--result-db <path>
This specifies where functional test results are stored.
Example:
LoadGen.FunctionalEngine.exe --project "Login Test" --result-db "C:\LoadGen\Results.db"
Notes:
- if omitted, the engine auto-discovers the results database in common locations
- if the database does not exist, the required tables are created automatically
Output options
Output directory
--output <path> -o <path>
This defines the output folder for result files.
Example:
LoadGen.FunctionalEngine.exe --project "Login Test" --output "C:\LoadGen\Output"
Note:
- when an automation XML file is used, the output path defined in the XML takes precedence
WebTesting options
Headless mode
--headless [true|false]
This determines whether WebTesting runs with a visible browser window or in the background.
Default:
true
Example:
LoadGen.FunctionalEngine.exe --project "Login Test" --headless false
Disable headless mode
--no-headless
Shortcut to force visible browser mode.
Example:
LoadGen.FunctionalEngine.exe --project "Login Test" --no-headless
This is especially helpful for:
- debugging browser actions
- checking whether selectors or timing behave as expected
- troubleshooting login flows and redirects
Other options
Show version
--version -v
Displays the version of the FunctionalEngine executable.
Show help
--help -h
Displays the usage information and available parameters.
Exit codes
The FunctionalEngine uses the following exit codes:
| Exit code | Meaning |
|---|---|
| 0 | Success or informational command |
| 1 | One or more tests failed |
| 2 | Configuration error |
| 3 | Project not found |
| 4 | Runtime error |
Explanation
- 0 means the test passed, or the command was informational only, such as
--helpor--list-projects - 1 means the test ran, but at least one testcase failed
- 2 means there is a setup issue such as bad arguments or a missing file
- 3 means the project name could not be found in the repository database
- 4 means an unhandled runtime exception occurred during execution
These codes are useful when integrating FunctionalEngine with:
- scheduled tasks
- PowerShell scripts
- CI/CD pipelines
- external monitoring or orchestration tools
Examples
Start in interactive mode
LoadGen.FunctionalEngine.exe
If a terminal is available, you can select the project from a menu.
List projects
LoadGen.FunctionalEngine.exe --list-projects
Shows all projects and testcase counts.
Run a project directly
LoadGen.FunctionalEngine.exe --project "Login Test"
Executes the project using the default repository database.
Run from automation XML
LoadGen.FunctionalEngine.exe --automation "C:\Tests\test.xml"
Executes the test using the settings stored in the XML file.
Run with visible browser for WebTesting
LoadGen.FunctionalEngine.exe --project "Login Test" --no-headless
Useful for browser-based debugging.
Running elevated vs normal user context
One of the key changes in the 2026 Q1 release is that functional tests no longer need to be launched only from an elevated Studio session. The new FunctionalEngine can be run:
- as a normal user
- as an elevated administrator
- from a script or scheduled task
- from a headless environment
When to run as normal user
Use normal user context when:
- the application under test runs as the logged-in user
- no administrative permissions are required
- you want behavior that is as close as possible to a standard end-user session
When to run elevated
Use elevated execution when:
- the test interacts with elevated applications
- access to protected folders, registry locations, or services is required
- the environment itself requires administrator rights for automation
Important:
The FunctionalEngine does not automatically elevate itself. If elevation is required, start it explicitly using Run as Administrator or through an elevated command prompt or script.
Recommended workflow
A typical workflow is:
- Create and maintain the functional project in Studio
- Save the project into the repository database
- Use
--list-projectsto verify the project is available - Execute the project with FunctionalEngine
- Review the results database and output folder
This separates:
- design time in Studio
- execution time in FunctionalEngine
That separation makes it easier to automate and support production-like functional test execution.
Troubleshooting
Project not found
If you get exit code 3:
- verify the project name exactly
- run
--list-projectsto confirm the project exists - verify the repository database path
Missing files or invalid arguments
If you get exit code 2:
- verify the automation XML path
- verify repository and result database paths
- check for quoting issues in command line arguments
Browser does not appear
If running WebTesting and no browser is shown:
- remember that headless mode is enabled by default
- use
--no-headlessto make the browser visible
Test behaves differently than Studio
If the same test behaves differently than when run from Studio:
- check whether Studio was elevated and FunctionalEngine is not, or vice versa
- verify repository and result database paths
- verify that the automation XML does not override your command line parameters
Summary
The LoadGen FunctionalEngine replaces the earlier dependency on running functional tests directly from an elevated Studio session. Starting with the 2026 Q1 release, functional tests can now be executed through a dedicated command line engine in either elevated or standard user context.
This provides:
- more flexible execution
- cleaner automation
- better support for scheduling and scripting
- simpler troubleshooting for functional and WebTesting scenarios
For most environments, this is the recommended way to run functional tests outside of Studio.