Silk Test Workbench is a GUI testing product that tries to act like a human user in order to achieve meaningful test results under automation conditions. A test performed by Silk Test Workbench should be as valuable as a test performed by a human user while executing much faster. This means that Silk Test Workbench requires a testing environment that is as similar as possible to the testing environment that a human user would require in order to perform the same test.
Manually testing the UI of a real application requires physical input and output devices like a keyboard, a mouse, and a display. Silk Test Workbench does not necessarily require physical input devices during test replay. What Silk Test Workbench requires is the ability of the operating system to perform keystrokes and mouse clicks. The Silk Test Workbench replay usually works as expected without any input devices connected. However, some device drivers might block the Silk Test Workbench replay mechanisms if the physical input device is not available.
The same applies to physical output devices. A physical display does not necessarily need to be connected, but a working video device driver must be installed and the operating system must be in a condition to render things to the screen. For example, rendering is not possible in screen saver mode or if a session is locked. If rendering is not possible, low-level replay will not work and high-level replay might also not work as expected, depend on the technology that is used in the application under test (AUT).
Silk Test Workbench does not directly support virtualization vendors, but can operate with any type of virtualization solution as long as the virtual guest machine behaves like a physical machine. Standard peripherals are usually provided as virtual devices, regardless of which physical devices are used with the machine that runs the virtual machine.
From an automation point of view, a cloud instance is not different to a virtual machine. However, a cloud instance might run some special video rendering optimization, which might lead to situations where screen rendering is temporarily turned off to save hardware resources. This might happen when the cloud instance detects that no client is actively viewing the display. In such a case, you could open a VNC window as a workaround.
If Silk Test Workbench is used to interact with the remote desktop, remote view, or remote app window, only low-level techniques can be used, because Silk Test Workbench sees only a screenshot of the remote machine. For some remote viewing solutions even low-level operations may not be possible because of security restrictions. For example, it might not be possible to send keystrokes to a remote application window.
Silk Test Workbench requires an interactively-logged-on full-user session. Disable anything that could lock the session, for example screen savers, hibernation, or sleep mode. If this is not possible because of organizational policies you could workaround such issues by adding keep alive actions, for example moving the mouse, in regular intervals or at the end of each test case.