How Test Services works
Test Services is a web application, installed with OpenLab CDS, that verifies a deployment works. Its core framework tests check the underlying OpenLab platform, and the OpenLab CDS plug-in adds the tests specific to OpenLab CDS. Understanding how it is laid out across your machines, and how those machines coordinate, helps you decide where to run a test. It also explains why a given test appears on one machine but not another. This page describes that model; for the procedures themselves, follow the links to the relevant how-to guides.
A browser application on every machine
Test Services is installed automatically when you install OpenLab CDS, and a copy runs on every machine in the deployment. Because it is reached over the network through a browser, you can open the application on one machine from any other machine in your lab. There is no separate client to install.
Each machine serves its own Test Services instance. When you open the application, you are working against that machine: the tests it offers, and the results it shows, belong to it. The address you use depends on the machine's role, and on a client a non-standard port is involved. The addresses are listed in Log in to Test Services.
How a test reaches OpenLab CDS
Test Services does not own user accounts, licenses, or storage. It works through the shared OpenLab platform services that already manage your deployment. When you log in, Test Services validates your credentials against OpenLab Shared Services rather than its own user store. As a result, you use the same credentials as OpenLab CDS. For the detail, see About authentication.
In the same way, the tests reach OpenLab CDS through its platform interfaces. A test such as the Workflow Test drives a real, automated acquisition through OpenLab CDS and then checks the outcome. A licensed test acquires its license from the platform's licensing service before it runs. This is why Test Services reflects the true state of your deployment: it exercises the same software and services your lab uses every day.
What runs where
The tests on a machine depend on the machine's role in the deployment and on which plug-ins and licenses are installed. Test Services contributes a core framework, and plug-ins add the tests for specific scenarios, so a test only appears where its plug-in is present and applicable. By default, each machine shows the tests recommended for its role, and you can choose to show all available tests. The reasoning behind the recommended set is described in System types and recommended tests.
Test Services supports the OpenLab CDS topologies your lab is likely to use, from a single Workstation through client/server and enterprise configurations. Each topology installs a different set of tests and is reached at a different address. The deployment diagrams, the tests per machine type, and the per-topology addresses are in Deployment architecture; for the supported configurations, see System requirements.
Coordinating a multi-machine deployment
When Test Services runs on more than one machine, the per-machine instances need to act as one deployment for scheduling, notifications, and shared configuration. Test Services Central Management (Central Management) provides that coordination. It runs on the server and workstation machines and keeps a shared record that the instances register with. This keeps scheduled tests, email notifications, and global settings consistent across the whole deployment, rather than configured machine by machine.
In a clustered, load-balanced deployment, Central Management ensures that scheduled work runs once rather than once per node. It also ensures that concurrent changes from different machines do not produce duplicate records. This coordination is what lets you schedule tests centrally (see Schedule tests) and receive a single notification per run (see Set up email notifications).
If Central Management has not been activated, the Scheduler and Notifications areas are unavailable until an administrator activates it. Individual tests and history still work without it.
See also
- Deployment architecture: the supported topologies, the tests per machine type, and the address for each.
- System types and recommended tests: why the available and recommended tests differ by machine.
- The verification run: what happens when you run a test.
- About authentication: how Test Services validates who you are.
- System requirements: supported topologies and browsers.
- Log in to Test Services: the address to use for each deployment type.