The asynchronous testing functionality for protocol-level record/replay is designed for Web applications that use asynchronous communication patterns such as polling, long-polling, and push. The characteristics of such applications is periodic, event-based, or server-triggered content updates without user interaction. Asynchronous web application testing on protocol-level is less resource intensive, but it is more challenging to script as opposed to the BDLT approach, which is resource intensive but automates the scripting process entirely during recording.
Silk Performer offers a dedicated project type (Web (Async)) to facilitate recording of web applications that make use of asynchronous communication patterns. While recording a user transaction, the Silk Performer recorder creates a so-called Silk Performer capture file, which contains the entire traffic of the recorded session. After saving, the capture file is opened in the Workbench for further analysis and processing. Before generating a script from the captured traffic, you can configure recording rules and other settings, which are applied during the script generation process. Note that it is possible to generate several scripts (with different options) from the same capture file.
For each of the previously mentioned asynchronous communication patterns Silk Performer offers a web API function to create an asynchronous communication channel to the web server:
Each WebAsyncPrepare... function call starts a dedicated asynchronous communication channel with the subsequent web function call.
The WebAsyncPrepare... functions take an optional BDL callback function as parameter. The callback function is called to notify the virtual user about certain events. For a detailed description of the events, refer to the BDL reference.
Asynchronous communication channels are active in parallel to normal virtual user activity, whereas callback functions are called by the web replay engine at many but specific occasions during script execution.
Sometimes virtual user activity needs to be synchronized with callback function execution. A typical example is a situation where a virtual user needs to wait for information from the server, which is delivered via an asynchronous communication channel.
At the time where the information is required, the virtual user calls the function UserWaitFor. When the data arrives, the related callback function is called. This function retrieves and stores the awaited information. At this stage, the callback function signals an event to the virtual user by calling the function UserSignal. The virtual user can then safely access the information stored by the callback function.