Verification Functions for Terminal-Emulation Applications

TrueLog Explorer allows you to easily add content verifications to test scripts to verify that the content that is to be sent by servers is in fact received by clients under real-world conditions. Content verification functions may be inserted for any terminal emulation API call. For example, for a WebTelnetSendCommand function call in which input data is entered, you can insert a return value verification function. Verification functions can be inserted through context menus in both Host Screen view and Host Screen Info view.

By comparing replay test runs with record test runs, a uniquely powerful approach to the challenge of testing end-user experience in client/server environments, TrueLog Explorer allows you to confirm visually whether or not input data are actually downloaded and displayed by clients while terminal-emulation applications are under heavy load. This allows you to detect a class of errors that other terminal emulation traffic simulation tools are not able to detect: errors that occur only under load that are not detected with standard load test scripts.

Content verifications remain useful after system deployment as they can be employed in ongoing performance management.

By right-clicking an input field that you want to have verified in Host Screen or Host Screen Info views, the required verification function can be generated and inserted into your BDL script. TrueLog Explorer offers three pre-enabled verification functions (WebTelnetScreenVerifyText, WebTelnetScreenVerifyField, and WebTelnetScreenVerifyStatus).

Content Verification vs. Field Verification

Content verifications enable you to select and setup verifications for onscreen text strings in Host Screen view, regardless of their placement on screen. Field verifications enable you to set up verifications for pre-defined regions (fields) within a terminal view. An application might define an entire screen as a single field, or a page might be built of header fields, footer fields, body fields, and so forth. Fields are often used as input areas, but they do not necessarily need to accept input. On-screen characters do not necessarily need to reside within fields.