Main: Functional Testing

Main: Functional Testing

Overview

Use this page to review the functional testing workflow and open package upload or the dashboard. Functional Testing runs a LoadGen Studio functional project headless on enrolled Windows engines, instead of requiring an operator to drive the project interactively on a single machine, and keeps every run's results, screenshots, dashboards, and reports on the appliance.

Before this page is useful, a Studio functional project must exist as a Testproject repository.db built in LoadGen Studio, and at least one Windows host must be enrolled as an engine. What you upload here as a package feeds the run queue, which an enrolled engine claims and executes; the appliance then turns each run's rows into a single verdict and keeps the resulting steps, screenshots, logs, and reports for review. Those downstream results are what you later check in the dashboard and reports.

This page itself is informational: it lays out the package, engine, run queue, and verdict relationship in one diagram, summarizes the five-step lifecycle from Upload through Report, and gives you two entry points, uploading a new package or opening the results dashboard, plus a link that explains how the single verdict rule is computed.

Key concepts

  • package - A LoadGen Studio functional project (Testproject repository.db) uploaded to the appliance so it can run headless instead of interactively. (related: Functional Testing: Packages)
  • engine - A Windows host running FunctionalEngine.exe that enrolls with the appliance, then claims and downloads packages to run them headless or on an interactive desktop. (related: Functional Testing: Engines)
  • verdict - The single pass or fail judgment the platform computes for a run from its testcase rows (Ok or not) and validations measured against their threshold. (related: Functional Testing: Dashboard)
  • schedule - A cron-based recurring definition that queues a package's runs automatically and can attach alert profiles to notify on the outcome. (related: Functional Testing: Schedules)
  • LG014 cap - The functional testing licence's concurrency limit, shown here as 10 runs per licence, which caps how many runs can be in the queue or in progress at once. (related: LoadGen Cloud: Licensing)

When to use it

  • You are new to functional testing and need to see how a Studio project becomes a verdict before you upload anything.
  • You want the fastest route to upload a new or updated package without navigating the module's working pages individually.
  • You want the fastest route to the stability dashboard to check recent verdicts and pull reports.
  • You need to confirm what an engine does (claim, download, run) before troubleshooting a run that never starts.
  • You want to understand the LG014 concurrency cap before queuing a large batch of scheduled runs.
  • You need a plain-language explanation of how the platform derives a single verdict from testcase and validation rows.

Before you begin

  • A LoadGen Studio functional project exported as a Testproject repository.db, ready to upload as a package. Build and export this in LoadGen Studio.
  • At least one Windows host enrolled as an engine with FunctionalEngine.exe, confirmed on Functional Testing: Engines.
  • An active functional testing licence (LG014); without it the Upload a package and Dashboard links do not function.

Common workflows

Orient yourself before your first functional run

Persona: A load-test operator setting up functional testing for the first time

  1. Read the How a functional run works diagram to trace the path from LoadGen Studio through the appliance to Windows engines and Results.
    • Expect: You can see that a package moves from the Studio repository into a run queue, is claimed by an engine, and produces a verdict plus reports kept per retention.
  2. Confirm an enrolled Windows engine, for example svc.lg.plover, is online before you plan to queue a package.
    • Expect: You know which host will claim the run once a package is queued, instead of discovering no engine is available after uploading.
  3. Select Upload a package to submit your Testproject repository.db.
    • Expect: The page navigates to the package upload flow, where the project becomes a package available to the run queue.

Verify: Functional Testing: Packages lists the new package, and once an engine claims and completes a run, Functional Testing: Dashboard shows a verdict for it.

Steps

Step 1

Select Functional Testing in the left navigation.

Expected result: The Functional Testing overview opens, showing the How a functional run works diagram (LoadGen Studio, LoadGen appliance, Windows engines, Results) and the five-step lifecycle summary (Upload, Enroll, Run, Review, Report) below it, alongside the Upload a package and Dashboard buttons.

This overview orients you in the package, engine, and verdict workflow before you upload a project or check results.

  • Upload a package opens the package upload flow for a Studio project.
  • Dashboard opens the stability dashboard and reports.
  • The Studio projects, platform engines, one verdict rule link explains how the verdict is computed. Main: Functional Testing - step 1

Controls reference

Upload a package

Opens the package upload flow where you submit a Studio project (Testproject repository.db) as a package for headless execution.

When to use: Use it when you have a new or updated Studio functional project ready to run on your enrolled Windows engines.

Side effects: Navigation only from this overview; no package or run data changes here. The actual upload and package record are created on Functional Testing: Packages.

Dashboard

Opens the functional testing stability dashboard, showing verdicts and access to JUnit, HTML, CSV, and PDF reports with AI analysis.

When to use: Use it once packages have run, to review pass/fail trends and pull reports for a run or package.

Side effects: Read-only navigation; it does not change any run, package, or schedule state.

Studio projects, platform engines, one verdict rule

Opens further explanation of how the platform turns a run's testcase rows and validations into a single pass or fail verdict.

When to use: Use it when you need to understand the verdict rule before interpreting results on the dashboard or in reports.

Side effects: Read-only; opens informational content only, no run or configuration is changed.

Verify the result

The Functional Testing overview is open and shows the How a functional run works diagram connecting LoadGen Studio, the LoadGen appliance, Windows engines, and Results in sequence, plus the five-step lifecycle (Upload, Enroll, Run, Review, Report) below it. The LG014 cap note (10 runs per licence) is visible inside the appliance box, confirming your functional testing licence is active. Both Upload a package and Dashboard are enabled and clickable. If either button is missing or disabled, the first thing to check is whether your account holds an active LG014 functional testing licence.

Troubleshooting

  • Symptom: Upload a package or Dashboard is missing from the header. Fix: Confirm your account has an active LG014 functional testing licence entitlement; the module's links do not render without it.
  • Symptom: You are not sure a package will ever run after upload. Fix: Open Functional Testing: Engines and confirm at least one Windows host, for example svc.lg.plover, is enrolled with FunctionalEngine.exe before uploading.
  • Symptom: Scheduled or batch runs seem stuck in the queue instead of starting. Fix: Check the LG014 cap noted in the diagram (10 runs per licence); you may be at the concurrency limit for your licence.
  • Symptom: A package was uploaded but no verdict appears anywhere. Fix: Open Functional Testing: Run History to confirm an engine claimed and completed the run; a verdict only exists after that step finishes.
  • Symptom: Recurring runs never start on their own. Fix: This overview only links to upload and the dashboard; define the cron timing and alert profile on Functional Testing: Schedules.
  • Next step: Functional Testing: Packages - where Upload a package navigates to submit and manage Testproject repository.db packages
  • Prerequisite: Functional Testing: Engines - enroll the Windows engines that claim and run uploaded packages
  • Next step: Functional Testing: Dashboard - where Dashboard opens to review verdicts, stability trends, and reports
  • See also: Functional Testing: Schedules - define cron schedules and alert profiles for recurring package runs
  • See also: Functional Testing: Run History - check individual run status, steps, screenshots, and artifacts
  • See also: Configuration: Functional Testing: Retention - configure how long results, screenshots, and artifacts are kept
Was this article helpful?
0 out of 0 found this helpful