Also published on the product site: control-plane-farm-citratest-automated-testing.aspx
CitraTest automated testing on the glass – encode control-plane login storm and farm / sustained-path density as separate scripts with the same WaitForImage timer contract.
Direct answer: A green Workspace, Gateway, StoreFront, or RD Web check is not proof that the published app or business step is ready on screen. CitraTest® automated testing encodes two different paths on the glass: a login-storm / control-plane script that proves logon-to-shell (or first useful desktop), and a sustained-path / farm script that holds the session and exercises multi-step work users actually do. Sync with WaitForImage, time with StartTimer / StopTimer, prefer static bitmaps, reserve OCR for dynamic text – and never treat OCR as a wait.
Teams that collapse every regression into "log on, click around, hope" mix two failure modes. The control plane can absorb a rush of logons while the farm still paints a blank chart. The farm can look fine under a single calm session while Monday morning’s login storm still stalls on profile or broker spin-up. Control plane ≠ farm – and the automated tests should say so out loud.
This post is about CitraTest automated testing: how to build those scripts. It is not a concurrency sizing guide (that is CitraTest VU glass-level load testing) and not a production continuous-watch guide (that is CitraTest APM Publish → Scenario → SLA). Same glass definition of success; different operational question.
Illustrative method diagram – not customer results. The control plane is not the farm.
Two scripts, two questions
Separate the automation the same way operations separates the pain:
| Automation focus | What you encode | What a pass means |
|---|---|---|
| Login storm / control plane | Auth → broker/gateway → profile → session spin-up → desktop or client chrome ready | Logon-to-shell (or first useful pixel) appeared on the glass inside the timer you set |
| Sustained path / farm | Already-in-session multi-step work: open chart, submit order, post invoice, run payroll step | Each business screen state appeared under WaitForImage; timers name moments of truth, not protocol hops |
Reuse visual components where the UI is the same. Do not force one giant script to answer both questions every run. When login fails, you want a login-storm failure – not a vague "test red." When the chart never paints, you want a sustained-path failure – not another re-logon that hides density pain.
Illustrative method diagram – not customer results. Apply the same split when you automate Citrix, Microsoft RDS, AVD, browsers, and thick clients.
Automate the login storm (control plane) on the glass
Control-plane URL checks stay useful for HTTPS health and launch reachability. They do not prove the desktop is usable. A CitraTest login-storm automation script should:
- Drive the real client – Citrix Workspace, RDS / AVD client, thick client, or browser – with real mouse and keyboard.
- Define success as on-screen readiness – shell icons, start menu chrome, published-app tile that means work can start – not merely "ICA connected" or "HTTP 200."
- Sync with WaitForImage on static cues that survive theme and branding (prefer small, unique bitmaps).
- Time login-to-shell with StartTimer immediately after the initiating logon action and StopTimer after WaitForImage confirms the ready state.
- Keep the path short – prove the rush path, then hand off or stop. Do not bury three business transactions inside the same storm script.
When you later scale the same glass path under concurrency with CitraTest VU, the login-storm script is already honest about what "logged on" means. For automated testing today, honesty means the regression suite fails on the control-plane step that actually broke.
Automate the sustained path (farm) on the glass
Farm / density automation assumes a session is already usable – or starts from a known-good shell – then exercises the work that fills session hosts:
- Multi-step business flows – open chart, add line, submit, post, print, or whatever the shift cannot skip.
- One timer per moment of truth – app first paint, grid ready, confirmation screen – named after what the user sees.
- Stable sync cues – static toolbar icons and window chrome as bitmaps; dynamic IDs, MRNs, and order numbers via OCR after image sync.
- Clean desktop hygiene – close leftover windows so the next iteration does not inherit yesterday’s failure mode.
This is where "the farm" shows up for automated testing: inside the session, under the published app, on the pixels HDX and RDP deliver. URL green on the front door does not substitute for WaitForImage on the chart.
Illustrative / method diagram – not Tevron customer results. Control-plane indices can remain "healthy" while glass-level response climbs.
One measurement contract: see, wait, act, measure
Whether the script is login storm or sustained path, CitraTest keeps the same on-the-glass contract (User Guide / Quick Start guidance):
- Scripts encode the workflow on a Windows desktop.
- Playback sees the UI with bitmap images (and OCR when text is dynamic).
- Playback acts with real mouse and keyboard.
- WaitForImage synchronizes and verifies expected screen state before the next step.
- StartTimer / StopTimer capture on-screen response: StartTimer immediately after the initiating action; StopTimer immediately after WaitForImage confirms completion.
Prefer static bitmaps for sync cues that do not change. Reserve OCR for values that are unknown ahead of time. OCR is not a wait/sync – confirm readiness with image functions first, then read or assert dynamic text if needed. Keep baseline images small and unique; match display properties (resolution, color depth, theme, font smoothing) between capture and playback so "image not found" failures are real application delays, not environment drift.
Illustrative method diagram – not customer results. That pipeline is the measurement contract inside every automated test.
How this sits next to VU and APM (brief)
One glass definition of success travels across Tevron products without turning this article into a load or APM playbook:
- CitraTest – build and run the automated tests: login-storm scripts and sustained-path scripts as separate, honest paths.
- CitraTest VU – size those same paths under concurrency (login storm ramp, then density/sustain). See also Logon storm vs density.
- CitraTest APM – schedule the same class of glass transaction in production (Publish → Scenario → SLA).
Related reading: Advanced OCR for Automated Testing, The Control Plane Is Not the Farm (VU load testing), Publish → Scenario → SLA.
Closing: automate what the user feels – twice
Control plane ≠ farm. Automate the login storm so logon-to-shell failures stand alone. Automate the sustained path so density work inside the session stands alone. Keep WaitForImage as the sync, StartTimer/StopTimer as the clock, bitmaps for static cues, and OCR only for dynamic text. Then the suite tells you which path broke – before you confuse a green front door with a ready farm.
FAQ
Why should login-storm automation differ from sustained-path automation?
Login storm stresses steep concurrent or repeated logons through the control plane (broker, profile, session spin-up, first useful desktop). Sustained-path automation holds a session and exercises multi-step business work on the glass. Mixing them into one brittle script hides which failure mode broke.
What does CitraTest on-the-glass automated testing measure?
CitraTest drives the real client GUI with mouse and keyboard, syncs with WaitForImage (prefer static bitmaps), optionally uses OCR for dynamic text, and captures StartTimer/StopTimer for on-screen moments of truth such as login-to-shell, published-app first paint, or key transaction ready.
Can OCR be used as a wait or sync in CitraTest scripts?
No. Confirm readiness with image functions first (WaitForImage, ClickOnImage). Prefer bitmaps for static UI cues; reserve OCR for dynamic text. OCR is not a wait/sync.
How does this automated-testing post differ from CitraTest VU load testing and CitraTest APM?
This article is about building CitraTest automated tests for control-plane login storm vs farm sustained path. CitraTest VU sizes those paths under concurrency. CitraTest APM schedules the same class of glass path as a continuous production watch. Same WaitForImage and timer contract; different operational question.
Do CitraTest agents need to run on production session hosts?
No. For the glass path, CitraTest plays back from Windows machines with access to the client path. Nothing invasive is required on production session hosts for on-the-glass automation.
When you need that glass path without agents on production session hosts — schedule a demo. Product pages: CitraTest VU, CitraTest APM, and the Tevron.com blog.
Citrix, HDX, ICA, StoreFront, Workspace, Microsoft, Remote Desktop Services, RemoteApp, Azure Virtual Desktop, and related marks are trademarks of their respective owners. Tevron is not affiliated with those vendors. Names are used for identification only.