# 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](creating-automated-tests.md)
* [Known limitations for performance testing](known-limitations-for-performance-testing.md)