Performance test rules in Workflow Analyzer

Three Workflow Analyzer rules that check whether a project is ready for performance testing, including what each rule flags and how to resolve it.

Three Workflow Analyzer rules check whether your project is ready to run as a performance test. The rules appear in Studio while you design, so you can find problems before a test run. They apply to the Test Automation and Development scopes.

Rule	Name	Default severity
PT-BLK-001	Performance Test Blocking Issues	Warning
PT-ADV-001	Performance Test Advisories	Info
PT-APP-001	Performance Test Application Type	Info

PT-BLK-001: Performance Test Blocking Issues

This rule flags automation that a performance test can't run as intended. These findings must be resolved before performance results are reliable.

What it catches	Why it's a problem	What to do
Classic UI Automation browser activities, for example Open Browser and Browser Scope	The performance tooling can't measure the classic UI Automation stack, so results are unreliable.	Replace them with the modern UI Automation activities, such as Use Application/Browser and its child activities.
Incognito turned on where it can't work	Incognito requires UiPath.UIAutomation.Activities 26.10.0 or later, and the card must use a WebDriver or Chromium automation mode: WithGUI, Headless, DevTools, or DevToolsHeadless. If the rule can't determine the package version, the message says so.	Turn Incognito off for that card, or upgrade the package and select a supported browser mode.
Hardware Events input mode in a browser scope	Hardware Events go through the single input queue of the operating system. Results become erratic under load, and the test can't run several Virtual Users at once.	Switch the input mode to another option, such as Simulate or Chromium API.

The Hardware Events check flags a card or child activity when Hardware Events is set directly, inherited from a parent scope, or applied by default. The default applies to browser cards with no mode set in Windows projects. A child activity set to Same as card follows the mode of the card.

PT-ADV-001: Performance Test Advisories

This rule flags activities that run correctly but scale poorly when several Virtual Users share one machine. Each finding is advisory, not an error indicator.

What it catches	Why it matters	Suggestion
Global desktop interaction: window management, screen capture, and Send Hotkey with no target and no enclosing application scope	Virtual Users on the same machine interfere with each other, and these activities fail in headless runs.	Use activities that target a specific element by selector.
Image matching and OCR activities	They need a visual desktop session and don't scale across Virtual Users.	Use selector-based activities.
Computer Vision: a Computer Vision activity, or a target whose search steps include CV	Image recognition adds delay and varies from call to call, so measurements are unstable.	Use selectors to identify elements.
Local file access (Info level)	Concurrent Virtual Users access the same file paths, which causes locking errors and corrupted data.	Use a unique path for each Virtual User, isolated temporary folders, or API or database calls instead of files.

File access is harmless when each Virtual User already has its own path. The rule can't detect this, so it flags every use.

PT-APP-001: Performance Test Application Type

This rule always reports a result. It doesn't point out a mistake. It reports the application type that the robot uses for your project, and whether that type allows more than one Virtual User per machine.

Detected type	Virtual Users per machine
API (HTTP requests), Chrome, Edge	Multiple
Windows application, or classic UI Automation (Default)	One

The message reads similar to: Detected application type: Chrome. This test can run multiple Virtual Users per machine.

How the application type is chosen

• Classic UI Automation browser activities set the type to Default immediately, which allows a single Virtual User.
• Otherwise, the rule picks the type by priority: Windows, then Browser (Chrome or Edge), then API. If your project mixes types, the rule also reports Multiple application types detected … Resolved primary type by priority …. Without this rule, the mismatch only appears after a dry run.
• The rule assumes Windows when the type is unclear. Any desktop hint from PT-ADV-001 makes the project a Windows application: global desktop interaction, image matching or OCR, and file access. A custom activity that the analyzer can't inspect has the same effect, because it might interact with the desktop. A project with no hints also defaults to Windows.

Custom activities and libraries

The analyzer inspects the workflows of the custom (non-UiPath) activity packages in your project. It reads them from your local NuGet package cache, so it also reports problems inside a library.

When the analyzer can't inspect a package, PT-APP-001 lists it in a note and treats the project as a Windows application. The following table lists the possible reasons.

Reason	What to do
The package isn't in the local cache.	Restore the dependency and run the analysis again.
The package contains only compiled activities, with no workflow files.	No action is available. The analyzer can't inspect compiled activities.
No workflow in the package matches the activity name.	No action is available.
The workflow file couldn't be read.	No action is available.
The limit on the number of analyzed workflows was reached.	No action is available.

Related links

• Creating automated tests
• Known limitations for performance testing