LISA User Guide

User Manual:

Open the PDF directly: View PDF PDF.
Page Count: 678 [warning: Documents this large are best viewed by clicking the View PDF Link!]

1. LISA User Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1 Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1.1 Registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1.1.1 Starting the Registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1.1.2 Creating a Named Registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1.1.3 Changing the Registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1.2 Coordinator Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1.2.1 Creating Coordinator Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1.2.2 Monitoring Coordinator Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.1.3 Simulator Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.1.3.1 Creating Simulator Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.1.3.2 Monitoring Simulator Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.1.4 LISA Workstation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1.4.1 Opening LISA Workstation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1.4.2 Main Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.1.4.2.1 File Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1.4.2.2 Edit Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.1.4.2.3 View Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.1.4.2.4 System Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.1.4.2.5 Actions Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.1.4.2.6 Help Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.1.4.3 Main Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
1.1.4.4 Project Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
1.1.4.4.1 Project Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
1.1.4.4.2 Examples Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
1.1.4.4.3 Creating a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
1.1.4.4.4 Opening a Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
1.1.4.4.5 Project Panel Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
1.1.4.4.6 Project Panel Right-Click Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
1.1.4.5 Quick Start Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
1.1.4.5.1 Open Recent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
1.1.4.5.2 New WS Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
1.1.4.5.3 New Web Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
1.1.4.5.4 Send SOAP Doc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
1.1.4.5.5 Create VSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
1.1.4.5.6 Record WS VSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
1.1.4.5.7 VSI from WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
1.1.4.5.8 Learn More . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
1.1.4.6 Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
1.1.4.7 Tray Panels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
1.1.5 LISA Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
1.1.5.1 Opening the LISA Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
1.1.5.2 Web Server Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
1.1.6 Command-Line Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
1.1.7 Tutorials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
1.1.7.1 Tutorial 1 - Projects, Test Cases, and Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
1.1.7.2 Tutorial 2 - Data Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
1.1.7.3 Tutorial 3 - Filters and Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
1.1.7.4 Tutorial 4 - Manipulating Java Objects (POJOs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
1.1.7.5 Tutorial 5 - Running a Demo Server Web Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
1.1.7.6 Tutorial 6 - Testing a Website . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
1.1.7.6.1 Part A - Record and Run the LISA Bank Test Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
1.1.7.6.2 Part B - Running the Test Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
1.1.7.6.3 Part C - Modifying HTTP_HTML Request Test Steps (Optional) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
1.1.7.7 Tutorial 7 - Testing an Enterprise JavaBean (EJB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
1.1.7.8 Tutorial 8 - Testing a Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
1.1.7.9 Tutorial 9 - Examining and Testing a Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
1.1.7.10 Tutorial 10 - Staging a Quick Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
1.2 Building Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
1.2.1 Anatomy of a Test Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
1.2.1.1 Test Case Quick Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
1.2.1.2 Multi-tier-combo Test Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
1.2.1.3 Elements of a Test Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
1.2.1.4 Elements of a Test Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
1.2.2 Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
1.2.2.1 Specifying a Property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
1.2.2.2 Property Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
1.2.2.3 String Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
1.2.2.4 LISA Property Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
1.2.2.5 Common LISA Properties and Environment Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
1.2.2.6 Property Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
1.2.3 Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
1.2.3.1 LISA Project Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
1.2.3.2 Default Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
1.2.3.3 Adding a Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
1.2.3.4 Marking a Configuration as Active . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
1.2.3.5 Editing a Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
1.2.3.6 Copying a Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
1.2.3.7 Deleting a Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
1.2.3.8 Renaming a Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
1.2.3.9 Creating a New Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
1.2.3.10 Importing a Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
1.2.3.11 Applying a Configuration when Running a Test Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
1.2.4 Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
1.2.4.1 Adding a Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
1.2.4.1.1 Adding a Filter Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
1.2.4.1.2 Adding a Filter from an HTTP Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
1.2.4.1.3 Adding a Filter from a JDBC Result Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
1.2.4.1.4 Adding a Filter from a Returned Java Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
1.2.4.2 Deleting a Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
1.2.4.3 Reordering a Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
1.2.4.4 Dragging and Dropping a Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
1.2.4.5 Types of Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
1.2.4.5.1 Utility Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
1.2.4.5.2 Database Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
1.2.4.5.3 Messaging_ESB Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
1.2.4.5.4 HTTP_HTML Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
1.2.4.5.5 XML Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
1.2.4.5.6 Web 2.0 Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
1.2.4.5.7 Java Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
1.2.4.5.8 VSE Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
1.2.4.5.9 Pathfinder Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
1.2.5 Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
1.2.5.1 Adding an Assertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
1.2.5.1.1 Adding an Assertion Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
1.2.5.1.2 Adding an Assertion from an HTTP Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
1.2.5.1.3 Adding an Assertion from a JDBC Result Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
1.2.5.1.4 Adding an Assertion for Returned Java Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
1.2.5.2 Assertions Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
1.2.5.3 Deleting an Assertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
1.2.5.4 Reordering an Assertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
1.2.5.5 Renaming an Assertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
1.2.5.6 Dragging and Dropping an Assertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
1.2.5.7 Configuring the Next Step of an Assertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
1.2.5.8 Types of Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
1.2.5.8.1 HTTP Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
1.2.5.8.2 Database Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
1.2.5.8.3 Web 2.0 Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
1.2.5.8.4 XML Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
1.2.5.8.5 Virtual Service Environment Assertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
1.2.5.8.6 Other Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
1.2.6 Data Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
1.2.6.1 Global and Local Data Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
1.2.6.2 Random Data Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
1.2.6.3 Example Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
1.2.6.4 Adding a Data Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
1.2.6.5 Deleting a Data Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
1.2.6.6 Reordering a Data Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
1.2.6.7 Renaming a Data Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
1.2.6.8 Moving a Data Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
1.2.6.9 Data Set Next Step Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
1.2.6.10 Data Sets and Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
1.2.6.11 Types of Data Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
1.2.6.11.1 Read Rows from a Delimited Data File Data Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
1.2.6.11.2 Create your own Data Sheet Data Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
1.2.6.11.3 Create your own Set of Large Data Data Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
1.2.6.11.4 Read Rows from a JDBC Table Data Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
1.2.6.11.5 Create a Numeric Counting Data Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
1.2.6.11.6 Read Rows from Excel File Data Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
1.2.6.11.7 Read DTOs from Excel File Data Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
1.2.6.11.8 Unique Code Generator Data Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
1.2.6.11.9 Random Code Generator Data Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
1.2.6.11.10 Message_Correlation ID Generator Data Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
1.2.6.11.11 Load a Set of File Names Data Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
1.2.6.11.12 XML Data Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
1.2.7 Companions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
1.2.7.1 Adding a Companion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
1.2.7.2 Companion Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
1.2.7.3 Deleting a Companion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
1.2.7.4 Reordering a Companion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
1.2.7.5 Types of Companions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
1.2.7.5.1 Web Browser Simulation Companion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
1.2.7.5.2 Browser Bandwidth Simulation Companion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
1.2.7.5.3 HTTP Connection Pool Companion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
1.2.7.5.4 Configure LISA to Use a Web Proxy Companion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
1.2.7.5.5 Set Up a Synchronization Point Companion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
1.2.7.5.6 Set Up an Aggregate Step Companion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
1.2.7.5.7 Java Protocol Companion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
1.2.7.5.8 Observed System VSE Companion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
1.2.7.5.9 VSE Think Scale Companion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
1.2.7.5.10 Create a Sandbox Class Loader for Each Step Companion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
1.2.7.5.11 Set Final Step to Execute Companion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
1.2.7.5.12 Negative Testing Companion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
1.2.7.5.13 Fail Test Case Companion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
1.2.7.5.14 XML Diff Ignored Nodes Companion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
1.2.7.6 LISA Hooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
1.2.8 Complex Object Editor (COE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
1.2.8.1 Invoking the COE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
1.2.8.2 Object Call Tree Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
1.2.8.3 Data Sheet and Call Sheet Panels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
1.2.8.4 Object Interaction Panels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
1.2.8.5 Using Data Sets in the COE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
1.2.8.6 Usage Scenarios for Simple Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
1.2.8.7 Usage Scenarios for Complex Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
1.2.9 Building Test Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
1.2.9.1 Adding a Test Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
1.2.9.1.1 Adding a Test Step (example) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
1.2.9.2 Configuring Test Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
1.2.9.3 Adding Filters, Assertions, and Data Sets to a Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
1.2.9.4 Common Test Step Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
1.2.9.5 Configuring Next Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
1.2.9.6 Setting a Starter Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
1.2.9.7 Generating Warnings and Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
1.2.9.8 Types of Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
1.2.9.8.1 Test Step Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
1.2.9.8.2 Web_Web Services Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
1.2.9.8.3 Java_J2EE Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
1.2.9.8.4 Other Transaction Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
1.2.9.8.5 Utilities Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
1.2.9.8.6 External_Subprocess Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
1.2.9.8.7 JMS Messaging Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
1.2.9.8.8 BEA Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
1.2.9.8.9 Sun JCAPS Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
1.2.9.8.10 Oracle Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
1.2.9.8.11 TIBCO Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
1.2.9.8.12 Sonic Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
1.2.9.8.13 webMethods Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
1.2.9.8.14 IBM Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
1.2.9.8.15 Virtual Service Environment Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
1.2.9.8.16 Custom Extension Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
1.2.10 Creating Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
1.2.10.1 Creating a Test Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
1.2.10.2 Opening a Test Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
1.2.10.3 Saving a Test Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
1.2.10.4 Test Cases in Model Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
1.2.10.5 Adding Test Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
1.2.10.6 Configuring the Next Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
1.2.10.7 Branching and Looping in a Test Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
1.2.10.8 Importing Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
1.2.10.9 Response (.rsp) Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
1.2.10.10 Test Case Toolbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
1.2.11 Building Subprocesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
1.2.11.1 Creating a Subprocess Test Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
1.2.11.2 Converting an Existing Test Case into a Subprocess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
1.2.11.3 Subprocess Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
1.3 Building Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
1.3.1 Building Staging Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
1.3.1.1 Creating a Staging Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
1.3.1.2 Staging Document Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
1.3.1.2.1 Staging Document Editor - Base Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
1.3.1.2.2 Staging Document Editor - Reports Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
1.3.1.2.3 Staging Document Editor - Metrics Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
1.3.1.2.4 Staging Document Editor - Documentation Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
1.3.1.2.5 Staging Document Editor - IP Spoofing Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
1.3.1.2.6 Staging Document Editor - Source View Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
1.3.1.3 Staging Document Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504
1.3.2 Building Audit Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504
1.3.3 Understanding Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506
1.3.3.1 Events Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506
1.3.3.2 Adding and Viewing Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508
1.3.3.3 Types of Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512
1.3.4 Generating Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516
1.3.4.1 Types of Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
1.3.4.1.1 LISA Whole Test Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
1.3.4.1.2 LISA Test Event Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
1.3.4.1.3 SNMP Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
1.3.4.1.4 JMX Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
1.3.4.1.5 TIBCO Hawk Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523
1.3.4.1.6 Windows Perfmon Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527
1.3.4.1.7 UNIX Metrics Via SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
1.3.5 Building Test Suites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533
1.3.5.1 Creating a Test Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533
1.3.5.2 Test Suite Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533
1.3.5.2.1 Test Suite Editor - Base Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534
1.3.5.2.2 Test Suite Editor - Reports Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537
1.3.5.2.3 Test Suite Editor - Metrics Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537
1.3.5.2.4 Test Suite Editor - Documentation Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539
1.4 Working with Model Archives (MARs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
1.4.1 Model Archive (MAR) Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
1.4.2 Explicit and Implicit MAR Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542
1.4.3 Creating MAR Info Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542
1.4.4 Creating Monitor MAR Info Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544
1.4.5 Editing MAR Info Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546
1.4.6 Building MARs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
1.4.7 Deploying to CVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
1.4.8 Make Mar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
1.5 Running Test Cases and Suites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548
1.5.1 Using the Interactive Test Run (ITR) Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 548
1.5.1.1 Starting an ITR Run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 549
1.5.1.2 Examining the Results of an ITR Run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551
1.5.1.3 Graphical Text Diff Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554
1.5.2 Staging Quick Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558
1.5.2.1 Test Monitor Window - Quick Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559
1.5.2.2 Starting and Stopping Quick Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565
1.5.3 Staging Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566
1.5.3.1 Test Monitor Window - Test Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566
1.5.3.2 Starting and Stopping Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571
1.5.4 Running Test Suites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572
1.5.4.1 Stage Suite Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572
1.5.4.2 Stage Suite Execution - Events Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573
1.5.4.3 Stage Suite Execution - Results Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574
1.5.4.4 Using the Load Test Optimizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575
1.5.5 Test Runner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576
1.5.5.1 Running a Model Archive (MAR) with Test Runner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577
1.5.5.2 Running a Test Case with Test Runner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577
1.5.5.3 Running a Suite with Test Runner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577
1.5.5.4 Other Test Runner Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578
1.5.5.5 Multiple Test Runner Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579
1.5.5.6 Test Runner Log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579
1.5.6 LISA Invoke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579
1.6 Cloud DevTest Labs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582
1.6.1 Labs and Lab Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582
1.6.2 Virtual Lab Manager (VLM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
1.6.3 DevTest Cloud Manager (DCM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584
1.6.4 Configuring LISA DCM Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584
1.6.5 Configuring ServiceMesh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588
1.6.6 Configuring vCloud Director . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590
1.6.7 Dynamic Expansion of Test Labs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 590
1.6.8 Listing the Available Labs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591
1.6.9 Starting a Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592
1.6.10 Deploying a Model Archive (MAR) to a Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
1.6.11 Stopping a Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
1.6.12 Cloud DevTest Lab Videos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
1.7 Continuous Validation Service (CVS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594
1.7.1 Opening the CVS Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594
1.7.2 CVS Dashboard Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595
1.7.2.1 Monitor Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595
1.7.2.2 Graphs Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
1.7.2.3 Events Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599
1.7.3 Deploying a Monitor to CVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601
1.7.4 Running a Monitor Immediately . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603
1.7.5 Viewing Test Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603
1.7.6 Email Notification Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604
1.7.7 CVS Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604
1.8 Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606
1.8.1 Report Generator Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606
1.8.1.1 Default Report Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606
1.8.1.2 Load Test Report Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607
1.8.1.3 XML Report Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607
1.8.2 Opening the Reporting Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607
1.8.3 Reporting Portal Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607
1.8.4 Filtering Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609
1.8.5 Viewing Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610
1.8.5.1 Reports - Graphical View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610
1.8.5.1.1 Reports - Graphical View - Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615
1.8.5.2 Reports - Grid View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626
1.8.5.3 Standard LISA Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629
1.8.5.4 Interpreting Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633
1.8.6 Exporting Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634
1.8.7 Changing Reporting Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637
1.9 Recorders and Test Generators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637
1.9.1 Recording a Website . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637
1.9.1.1 Recording a Website via HTTP Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638
1.9.1.1.1 Configure Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639
1.9.1.1.2 Start Recording . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639
1.9.1.1.3 View Recorded Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 640
1.9.1.1.4 View in ITR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643
1.9.1.2 Recording a Website via DOM Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644
1.9.2 Generating a Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644
1.10 Advanced Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650
1.10.1 Using BeanShell in LISA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650
1.10.1.1 Using BeanShell Scripting Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651
1.10.1.2 Using Date Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652
1.10.2 Class Loader Sandbox Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653
1.10.3 In-Container Testing (ICT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653
1.10.3.1 Access using EJB (J2EE Container Environments) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654
1.10.3.2 Access using RMI (Custom Java Server and Application Environments) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654
1.10.3.3 Testing your ICT Installation from LISA Workstation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655
1.11 Generating DDLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656
1.12 Appendix A - LISA Property File (lisa.properties) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656
1.13 Appendix B - Custom Property Files (local.properties, site.properties) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 671
LISA User Guide
LISA is a complete and collaborative automated testing solution.
TM
LISA provides complete test coverage, with the ability to invoke and verify the behavior of each component across the end-to-end application.
LISA provides automated testability for all the components in the technology stack.
LISA also builds portable, executable test cases that are easy to extend, easy to chain into workflows with other tests, and simple to integrate with
existing test repositories. LISA test cases are designed to be shared across different teams and environments, with the ability to easily attach prior
results and artifacts to extend them, and the ability to readily execute with different underlying data.
Several components require parameters that must be obtained from people knowledgeable about the System Under Test (SUT). This information
is identified throughout the guide. You will rarely be able to proceed with building and running the component without this information.
Getting Started: This section provides an overview of the registry, coordinator server, simulator server, LISA Workstation, the LISA
Console, and command-line utilities. In addition, this section contains a series of tutorials that illustrate various features of the
product.
Building Test Cases: This section contains information about the important building blocks of LISA test cases, such as properties,
configurations, filters, assertions, and data sets.
Building Documents: This section describes details of building various documents such as staging documents and audit
documents.
Working with Model Archives (MARs): The main deployment artifact in LISA is a type of file referred to as a Model Archive
(MAR).
Running Test Cases and Suites: There are some utilities within the Workstation that facilitate running test cases, not as
production tests, but more to validate and tune your test case. This section has information about staging and running individual
tests and test suites, in the workstation environment and on LISA Server.
Cloud DevTest Labs: You can use use cloud-based infrastructure to provision development and test environments.
Continuous Validation Service (CVS): The Continuous Validation Service (CVS) lets you schedule tests and test suites to run on
a regular basis over an extended time period.
Reports: There are a wealth of features related to the generation and capture of data for the purpose of reporting results.
Recorders and Test Generators: In addition to building test cases from the ground up, there are many tools to automate or
semi-automate the creation of a test case. These tools range from recorders that can follow your actions through a system and
produce a test case for you, to smart test generators that can build a test case for you based on some basic information. For
example, if you have the Web Service Definition Language (WSDL) file from a web service, LISA can build a test case to test that
web service.
Access Control (ACL): LISA provides role-based access control. This feature is also known as ACL.
Advanced Features: This section deals with advanced features and explains ways for Java developers to customize and extend
LISA, and use it in ways that require knowledge of Java.
Appendix A - LISA Property File (lisa.properties): This appendix lists properties in the LISA property file.
Appendix B - Custom Property Files (local.properties, site.properties): This appendix lists properties included in the two custom
property files.
Getting Started
This section provides an overview of the registry, coordinator server, simulator server, LISA Workstation, LISA Console, and command-line
utilities.
This section also contains a series of tutorials that illustrate various features.
In this section, the following topics are covered:
Registry
Coordinator Server
Simulator Server
LISA Workstation
LISA Console
Command-Line Utilities
Tutorials
1.
2.
1.
Registry
The registry provides a central location for the registration of all LISA Server and LISA Workstation components.
The registry keeps track of the locations of any LISA runtime components and provides lookup to their locations for each registered component.
The registry also provides the web consoles for server administration, reporting, CVS, and Pathfinder. The common JMS provider used for
component-to-component communication is started and run in the registry process. The broker for LISA-deployed Java agents is also in the
registry.
The fully qualified name of the registry is . For example:tcp://hostname-or-IP-address:2010/registry-name
tcp://localhost:2010/Registry
tcp://myserver:2010/Registry
tcp://myserver.example.com:2010/Registry
tcp://172.24.255.255:2010/Registry
LISA Workstation includes the , which lets you monitor the test cases, simulators, coordinators, and virtual environments for aRegistry Monitor
test suite.
The registry is associated with at least one , named the Default lab. If you create a coordinator, simulator, or VSE server without specifying alab
lab, then the server belongs to the Default lab.
Starting the Registry
Creating a Named Registry
Changing the Registry
Starting the Registry
The procedure for starting the registry depends on whether is enabled.access control (ACL)
As of release 6.0.4, the second procedure is obsolete. You do not need to provide a user name and password when ACL is
enabled.
To start the registry when ACL is not enabled
Do one of the following:
(Windows) Open a command prompt, navigate to the directory, and enter the following command:LISA_HOME\bin
Registry
(Windows) Click .Start Menu > All Programs > LISA > Registry
(Windows) Double-click the file in the directory.Registry.exe LISA_HOME\bin
(UNIX) Open a terminal window, navigate to the directory, and enter the following command:LISA_HOME/bin
./Registry
Wait until the following message appears:
LISA Registry Ready.
To start the registry when ACL is enabled
Do one of the following:
(Windows) Open a command prompt, navigate to the directory, and enter the following command:LISA_HOME\bin
Registry -u username -p password
(UNIX) Open a terminal window, navigate to the directory, and enter the following command:LISA_HOME/bin
1.
2.
1.
2.
3.
4.
./Registry -u username -p password
Wait until the following message appears:
LISA Registry Ready.
Creating a Named Registry
To create a named registry, run the registry executable with the option:-n
LISA_HOME/bin/Registry -n RegistryName
The following examples create a registry named registry1.
This example is based on a Windows installation:
cd C:\Lisa\bin
Registry -n registry1
This example is based on a UNIX installation:
cd Lisa/bin
./Registry -n registry1
Changing the Registry
While you are working in LISA Workstation, you can switch to another registry.
To change the registry
From the main menu, select System > Registry > Change LISA Registry.
The Change LISA Registry dialog appears.
Enter the registry name, or open the drop-down list and select a previously used registry.
Select or clear the Prompt on Startup check box. If the check box is selected, the Set LISA Registry dialog opens when you start LISA
Workstation. If the check box is cleared, LISA Workstation will connect to the last connected registry on start up.
Click OK.
If one or more consoles are open within LISA Workstation, a dialog indicates that the consoles will be closed.
4.
5. Click Yes.
Coordinator Server
Coordinator servers receive the test run information in the form of documents, and coordinate the tests that are run on one or more simulator
.servers
The coordinator server manages metric collection and reporting, and communicates the test data to LISA Workstation for monitoring purposes. A
LISA server environment can have, and commonly does have, more than one coordinator server.
The coordinator server runs LISA tests when presented with a staging document, test case, default configuration and alternatively an alternate
config.
The default name of a coordinator server is set by the property.lisa.coordName
lisa.coordName=Coordinator
The fully qualified name of a coordinator server is .tcp:// :2011/hostname-or-IP-address coordinator-name
Creating Coordinator Servers
To create a coordinator server, run the following command:
LISA_HOME/bin/CoordinatorServer -n CoordinatorServerName -m RegistryName
The following examples create a coordinator server named .coordinator1
This example is based on a Windows installation:
cd C:\Lisa\bin
CoordinatorServer -n coordinator1 -m tcp://localhost:2010/registry1
This example is based on a UNIX installation:
cd Lisa/bin
./CoordinatorServer -n coordinator1 -m tcp://localhost:2010/registry1
You can add the coordinator to a named by using the option. If you do not specify the option, then the coordinator is added to the Defaultlab -l -l
lab.
If is enabled, use the and options to specify your user name and password.access control (ACL) -u -p
As of release 6.0.4, the and options are obsolete. You do not need to provide a user name and password when ACL is-u -p
enabled.
You can display the version number by using the option.--version
For information about running the coordinator server as a service, see .Running Server Components as Services
Monitoring Coordinator Servers
If LISA Workstation is attached to the associated registry, then a running coordinator server appears in the .LISA Registry Monitor
The following image shows the Coord Servers tab of the LISA Registry Monitor.
The coordinator server also appears in the network graph of the Server Console.
The following image shows an example of the network graph. The Default lab contains one coordinator.
If you click the coordinator server in the network graph, then a details window appears.
Simulator Server
Simulator servers run the tests under the supervision of the .coordinator server
Virtual users or test instances are created and run on the simulator servers. The number of virtual users, and hence the number of simulator
servers deployed, depend on the nature of the tests being performed. Each virtual user is in communication with the client system.
For large tests with many virtual users, virtual users can be distributed among several simulator servers.
The default name of a simulator server is set by the property.lisa.simulatorName
lisa.simulatorName=Simulator
The fully qualified name of a simulator server is .tcp://hostname-or-IP-address:2014/simulator-name
Creating Simulator Servers
To create a simulator, run the following command:
LISA_HOME/bin/Simulator -n SimulatorName -m RegistryName
The following examples create a simulator named .simulator1
This example is based on a Windows installation:
cd C:\Lisa\bin
Simulator -n simulator1 -m tcp://localhost:2010/registry1
This example is based on a UNIX installation:
cd Lisa/bin
./Simulator -n simulator1 -m tcp://localhost:2010/registry1
You can add the simulator to a named by using the option. If you do not specify the option, then the simulator is added to the Default lab.lab -l -l
You can specify the number of virtual users for this simulator by using the option. For example:-i
Simulator -n simulator1 -m tcp://localhost:2010/registry1 -i 100
If is enabled, use the and options to specify your user name and password.access control (ACL) -u -p
As of release 6.0.4, the and options are obsolete. You do not need to provide a user name and password when ACL is-u -p
enabled.
You can display the version number by using the option.--version
When creating a simulator, you can override the default port number by adding a colon and the non-default port number to the option. For-n
example:
Simulator -n testSim1:35001
To run multiple simulators, use the command prompt to create the simulators as shown earlier.
Simulators will try port 2014 first if the port number is not specified as part of the name. If 2014 is taken, it will try 2015, 2016, and so on, up until
port 2024 before giving up.
For more information about port usage, see .Default Port Numbers
For information about running the simulator as a service, see .Running Server Components as Services
Monitoring Simulator Servers
If LISA Workstation is attached to the associated registry, then a running simulator appears in the .LISA Registry Monitor
The following image shows the Simulators tab of the LISA Registry Monitor.
The simulator also appears in the network graph of the Server Console.
The following image shows an example of the network graph. The Default lab contains one coordinator and one simulator.
If you click the simulator in the network graph, then a details window appears.
LISA Workstation
LISA Workstation is a single, easy-to-use, integrated environment for developing, staging, and monitoring tests.
You can work in a LISA Workstation version or in a LISA Server environment.
In LISA Workstation, the tests are managed and run within the Workstation environment. LISA Workstation is a test client used by
QA/QE, development, and business analysis teams to test rich browser and web user interfaces, and the building blocks below the user
interface. LISA Workstation is used to build and stage, all in a code-less manner: unit, functional, integration, regression, and business
process testing. It requires a LISA registry to run. Tests are managed and run within the LISA Workstation environment (test authoring
IDE), which runs embedded coordinator and simulator servers.
In LISA Server, the tests are also managed and run within the Workstation environment. The workstation then connects to the server to
deploy and monitor tests that were developed in LISA Workstation.
The server-side engine for LISA test cases and virtual services (test and virtual service model authoring IDE) is used to manage, schedule, and
orchestrate LISA test cases for unit, functional, load, and performance tests on a continuous basis.
Opening LISA Workstation
Main Menu
Main Toolbar
Project Panel
Quick Start Window
Tables
Tray Panels
Opening LISA Workstation
When you open LISA Workstation, you are prompted to specify a .registry
If your computer has an installation of LISA Server, then you can use either of the following:
1.
2.
3.
4.
A registry that is running on your local computer
A registry that is running on a remote computer
If your computer has an installation of LISA Workstation, then you must use a registry that is running on a remote computer.
For information about how to specify the registry when SSL is enabled, see .Using SSL to Secure Communication Between Components
To open LISA Workstation
Do one of the following:
Open a command prompt, go to the directory, and run the LISA Workstation executable.LISA_HOME/bin
If you have a LISA application icon on your desktop, double-click the application icon.
(Windows) Click .Start Menu > All Programs > LISA > LISAWorkstation
The Set LISA Registry dialog appears.
Accept the default registry, or specify a different registry.
Click OK.
If is enabled, then the Login dialog appears.access control (ACL)
Enter your user name and password, and click Login.
Main Menu
The main menu includes menu options for all the major functions available in LISA Workstation. The main menu options available are dynamic to
the selections at times. They are covered in detail here for the most common choices available.
There are some varying menus and also drop-down menus and toolbars available throughout LISA Workstation.
The items on this menu are dynamic. The items available can be controlled by your LISA administrator as part of your security
profile.
File Menu
Edit Menu
View Menu
System Menu
Actions Menu
Help Menu
File Menu
The items on this menu are dynamic. The items available can be controlled by your LISA administrator as part of your security
profile.
The File menu has the standard items related to file manipulation.
File > New
File > New shows a secondary menu where you can create a LISA project or create one of the test documents: test case, VS model, VS image,
staging document, suite or test audit.
From this menu, you can create LISA documents within the project that is open in LISA Workstation or outside of the project. By default, the
current directory selection is the folder of the open project.Tests
Project: Creates a new project. For more information see .Creating A New Project
Test Case: For additional information see .Creating Test Cases
VS Model: . For additional information see the Requires an additional license . LISA Virtualize Guide
VS Image: . For additional information see the .Requires an additional license LISA Virtualize Guide
Staging Document: For additional information see .Building Staging Documents
Suite: For additional information see .Building Test Suites
Test Audit: For additional information see .Building Audit Documents
Examples Project: Creates a new examples project. Specify a location for the new project in the dialog, click OK, and the
LISA_HOME/examples contents will be copied into a new project.
File > Open
File > Open shows a secondary menu where you can open either an existing LISA project or one of the six major LISA documents: test case, VS
model, VS image, staging document, suite or test audit.
You can browse for the document to open by looking in the file system, on the LISA classpath, or as a URL. LISA keeps a record of the most
recent documents you have opened, and lists them on the Quick Start Window - Open Recent.
See for additional information on the choices available, as they are the same as File > Open.File > New
You can open any LISA document either from within a LISA project or from outside a project by using the main menu File > Open > menu option.
If you select a document from a project that is different from the currently open project, the current project will close, and the project that the
selected document resides in will open, then the document will open.
File > Save
File > Save: Saves the current document.
File > Save As
File > Save As...: Saves the current document under a different name.
File > Close
File > Close: Closes the active tab.
File > Exit
File > Exit: Exits LISA Workstation.
Edit Menu
The items on this menu are dynamic. The items available can be controlled by your LISA administrator as part of your security
profile.
The Edit menu has the normal set of editing options.
Edit > Cut: Cuts the selected text.
Edit > Copy: Copies the selected text.
Edit > Paste: Pastes the selected text in the selected area.
Edit > Property Paste: Pastes the selected text in the selected area, and surrounds the pasted text with a set of double curly braces.
View Menu
The items on this menu are dynamic. The items available can be controlled by your LISA administrator as part of your security
profile.
The View menu contains a list of menus that deal with the viewing of the Reporting Console, CVS Dashboard, Pathfinder Console, Server
Console, LISA Dev Console, and others. You can also set the look and feel of LISA Workstation here and visit the LISA portal for more
information related to LISA.
Reporting Console: For additional information see .Reporting Console
CVS Dashboard: For additional information see .CVS Dashboard
Pathfinder Console: Invokes the Pathfinder Console. For more information, see the .Pathfinder Guide
Server Console: Provides a visual representation of the LISA network, starting with the registry, showing the connected coordinators and
their simulators, and VSE. The VSE Dashboard is accessed through the Server Console.
Dev Console: Lets you view detailed information about the workings of the LISA Agent. It also gives you the opportunity to add
extensions.
LISA Portal: Invokes the .LISA Console
Toogle Zoom Panel: Lets you toggle the Zoom panel.
Application Toolbar Settings: Lets you choose the interface of the Application Toolbar. You can select the toolbar settings to display
Icons and Labels, Icons only, Small Icons or no toolbar at all.
Model Editor Toolbar Settings: Lets you choose between large icons or smaller icons to be displayed on the LISA Model Editor menu.
Class Path: Lets you view and set the classpath.
System Menu
The items on this menu are dynamic. The items available can be controlled by your LISA administrator as part of your security
profile.
The System menu has a menu to manage the system registries and system messages. You can also edit the LISA properties, add JAR or zip files
to Hot Deploy or reset Hot Deploy Class Loader and set the tools.jar file here.
System > Registry
Registry: You can do all activities related to the LISA registry in this menu.
System > Registry > Change LISA Registry
Change LISA Registry: See for more information about this menu.Registry
System > Registry > Toggle LISA Registry Monitor
Toggle LISA Registry Monitor: You can toggle the LISA Registry Monitor, so that it can be viewed in LISA Workstation.
System > Registry > Shut Down LISA Registry
Shut Down LISA Registry: Shuts down the LISA registry.
A LISA registry is mandatory for LISA Workstation to remain open. You will be prompted to select a registry if the
registry is closed.
System > Registry > Reset LISA Registry
Reset LISA Registry: Resets the LISA registry, which will reset the registry information in the system.
System > Registry > View LISA Registry Status
View LISA Registry Status: Displays a dialog listing the number of coordinator servers and simulator servers that are attached to the
current registry.
System > Messages
Messages: This menu is for the System Message settings.
Save: Save the system messages.
Clear: Clear the system messages.
Capture Level: Select the type of system messages to view: Error, Warn, Info (selected by default), Debug, or Show Stack Traces.
System > Edit LISA Properties
Edit LISA Properties: Opens the file in an editable window.lisa.properties
Use extreme caution if you choose to edit this file.
System > View Security Permissions
View Security Permissions: If access control (ACL) is enabled, displays the unique ID of your user name, roles that are assigned to
you, and permissions that you have.
System > Add Jar/Zip/Ear to Hot Deploy
Add Jar/Zip/Ear to Hot Deploy...: Displays a dialog to enter the name of a file to upload into the hot deploy directory. The file you upload
contains items that you want to add to LISA's classpath.
For more information see the .Installation and Configuration Guide LISA Installation and Configuration Guide
System > Reset Hot Deploy Class Loader
Reset Hot Deploy Class Loader: Displays a dialog where you can change the location of the current hot deploy directory.
For more information see the .Installation and Configuration Guide
System > Set Tools.jar
Set Tools.jar: Displays a dialog where you can enter, or browse to the location of a Tools.jar file. This file is required Java code needs to
be compiled. Several test steps and generators need to compile code.
If a Tools.jar file is available, the dialog will indicate that.
For more information see the .Installation and Configuration Guide
Actions Menu
The items on this menu are dynamic. The items available can be controlled by your LISA administrator as part of your security
profile.
The Actions menu has items related to staging test cases, running suites, recording test cases, staging quick tests, adding test steps, and
launching various tools. You will not see the full Actions menu as shown below unless you have a test case open.
Actions > Stage Test
Stage Test: This item is available for test cases. Opens a dialog where you can start the test case execution.
For more information, see .Staging Test Cases
Actions > Run
Run: This item is available for suites. It opens a dialog where you can configure and stage the suite.
For more information, see .Running Test Suites
Actions > Record Test Case for User Interface
Record Test Case for User Interface: Opens a new submenu to record test cases for HTTP Proxy or DOM Events.
For more information, see .Recorders and Test Generators
Actions > Start Interactive Test Run
Start Interactive Test Run (ITR): Click to start the Interactive Test Run (ITR) utility.
For more information, see .Using the Interactive Test Run (ITR) Utility
Actions > Stage a Quick Test
Stage a Quick Test: Click to stage a quick test.
For more information, see .Staging Quick Tests
Actions > Replay Test Case to Specific Point
Replay Test Case to Specific Point: Click to run a test to a specific point in a test case. You can replay the test in the ITR utility to any
given test step. A dialog is displayed, to let you enter the last step of the replay. This will populate the known state up to that point. This is
particularly useful if you want to examine properties like LASTRESPONSE that store the value of the last step response.
Actions > Create New Step
Create New Step: Opens a Steps panel with a list of all the available test steps.
The selected step will be added to the test case.
For more information, see .Building Test Cases
Actions > Launch Axis TCPMonitor
Launch Axis TCPMonitor: Launches an external application named TCPMonitor, which lets you monitor client/server communications.
For more information, see .http://ws.apache.org/axis/
Actions > Open UDDI Search Browser
Open UDDI Search Browser: Launches a UDDI search browser.
For more information, see the .Web Service test step
Actions > Graphical Text Diff
Graphical Text Diff...: Opens a graphical XML diff engine and visualizer.
For more information, see .Graphical Text Diff Utility
Actions > WSDL Bundler
WSDL Bundler: Lets you bundle a WSDL and any supporting documents into a single ZIP file. The ZIP file can be sent to ITKO Support
if you are experiencing problems using the WSDL.
The Destination file is specified as a file URL.
VSE Actions Menu
When you are working with virtual service models or virtual service images, the Actions menu will change to display options related to LISA
Virtualize.
This menu contains additional options for VSE users:
Replay VSE Model to a specific Point: Replays the VSE model to the point selected.
View Tracked Responses from the ITR run: Enables you to see transactions tracked in the ITR.
Help Menu
The items on this menu are dynamic. The items available can be controlled by your LISA administrator as part of your security
profile.
The Help menu includes information about Documentation, Runtime Information, LISA License settings, and debuggers.
Help > Documentation
Documentation: Opens the LISA documentation page.
Help > About
About: Shows the LISA version and build numbers.
Help > LISA Runtime Info
LISA Runtime Info: Shows current runtime information in two tabs, License Info (default) and System Properties.
LISA Runtime Info - License Info Tab
This tab gives information related to the LISA license.
Dump Heap: You can generate a heap dump file (HProf) through the LISA runtime panel. Click the Dump Heap button to produce the
heap dump.
This functionality is available only on Sun Java 6 Java runtimes. It is a diagnostic tool that can help ITKO support determine the
causes of OutOfMemory conditions. The heap is automatically dumped if an OutOfMemory condition occurs; this button is for
manually triggering a heap dump.
After the dump is created, a message indicates that the heap dump has been taken.
LISA Runtime Info - System Properties Tab
This tab provides information regarding the LISA system properties.
Help > Property Window
Property Window - Properties Tab
Opens up the LISA Property Window. You cannot update these values from this window.
Property Window - Patterns Tab
All the LISA properties are listed here. You can also generate string patterns from the tab.Patterns
Help > Regular Expression Helper
This option displays a simple window that can be used to experiment and verify how regular expressions match against any piece of text. Here,
you enter a Regex and a target string and the dialog highlights the match spans to verify that the Regex pattern itself is actually going to correctly
match your input data.
Help > LISA License Settings
LISA License Settings: Shows the current license settings.
For more information on LISA licensing and license settings, see " ."Licensing Approaches
Help > Enable Debug
Enable Debug: Turns on an extra level of debugging, and shows Java stack traces in the output log.
Help > Show HTTP Wire Debug
Show HTTP Wire Debug: Turns on a debug mode that captures all the handshaking (multiple request/responses that happen during
negotiation) to see what's happening during HTTP transactions.
The following image shows the HTTP Wire Traffic Viewer dialog.
Main Toolbar
The main toolbar of LISA Workstation contains icons for common functions.
The items on this toolbar are dynamic. The items available can be controlled by your LISA administrator as part of your security
permissions.
The following table describes each icon.
Icon Description Main Menu Equivalent
Creates a new project. File > New > Project
Opens an existing project. File > Open > Project
Saves the current document. File > Save
Lets you stage and deploy a test case or suite. Actions > Stage Test and Actions >
Run
Lets you switch to another registry. System > Registry > Change LISA
Registry
Shows and hides the LISA Registry Monitor. System > Registry > Toggle LISA
Registry Monitor
Opens the LISA Virtualize Recorder. File > New > VS Image > By recording
Opens the CVS Dashboard. View > CVS Dashboard
Opens the Pathfinder Console. View > Pathfinder Console
Opens the Dev Console. View > LISA Dev Console
Opens the Server Console. View > Server Console
Opens the Reporting Console. View > Reporting Console
Stops the test run. When you run a test case, this icon becomes a Play icon
until the run finishes. Not Applicable
Closes the test run. Not Applicable
Indicates when a cloud-based lab is being provisioned and then ready. Not Applicable
Project Panel
The following topics are available.
Project Overview
Examples Project
Creating a Project
Opening a Project
Project Panel Layout
Project Panel Right-Click Menu
Project Overview
A project is a collection of related LISA assets. The assets can include test cases, suites, virtual service models, service images, configurations,
audit documents, staging documents, data sets, monitors, and MAR info files.
In LISA Workstation, only one project can be open at a time.
The directory does not exist until you create a project for the first time.LISA_HOME/Projects
All the folders in the Project panel of LISA Workstation are the same as those created in the file system. You can check the directoryLISA_HOME
to see the folder structure and files.
You can import files into a project.
Examples Project
When you start LISA Workstation for the first time, the Project panel displays a project named .examples
The project includes the following :examples configurations
examples.itko.com.config
project.config
The file is the initial active configuration.project.config
You can open any of the sample files by double-clicking them. The appropriate editor will open in the right panel.
The actual project files are located in the directory.LISA_HOME/examples
MARInfos
AllTestsSuite
Suite MAR that includes the test suite AllTestsSuite, with all the .tst files and accompanying data files to run the AllTestsSuite. It also
includes the 1User1Cycle0Think staging document, the DefaultAudit audit document, and the project.config configuration file.
creditCheckValidate
Test-based Monitor MAR that includes the creditCheckValidate test case and the monitorRunBase staging document.
DatabaseModel
Virtual Service MAR that includes the DatabaseModel virtual service model and virtual service image.
OnlineBankingExternalCreditCheck-local
Test-based Monitor MAR that includes test case webservices-xml-fail, staging document Run1User1Cycle and project.config.
OnlineBankingExternalCreditCheck
Test-based Monitor MAR that includes test case webservices-xml-fail, staging document Run1User1Cycle, project.config and
examples.itko.com.config.
OnlineBankingJMStest-local
Test-based Monitor MAR that includes the ansync-consumer-jms test case and Run1User1Cycle staging document.
OnlineBankingJMStest
Test-based Monitor MAR that includes the ansync-consumer-jms test case, Run1User1Cycle staging document, and project.config and
examples.itko.com.config configuration files.
OnlineBankingTransactionMonitor-local
Test Based Monitor MAR that includes the multi-tier-combo test case, Run1User1Cycle staging document, all the data files to support the
test case, and project.config.
OnlineBankingTransactionMonitor
Test Based Monitor MAR that includes the multi-tier-combo test case, Run1User1Cycle staging document, all the data files to support the
test case, and project.config and examples.itko.com.config configuration files.
OnlineBankingWebServices-local
Test-based Monitor MAR that includes the webservices-xml test case, Run1User1Cycle staging document, and the project.config
configuration file.
OnlineBankingWebServices
Test-based Monitor MAR that includes the webservices-xml test case, Run1User1Cycle staging document, and project.config and
examples.itko.com.config configuration files.
rawSoap
Test MAR that includes the rawSoap test case, the 1User0Think_RunContinuously staging document, and the project.config configuration
file.
Audit Docs
DefaultAudit
Configurations
examples.itko.com
The examples.itko.com config file should be the active configuration file when you are running your examples against the ITKO examples
server at examples,itko.com. The only difference between it and the default project.config file is that instead of pointing to servers on
localhost, it points to the ITKO examples website.
project
The project.config file contains intelligent defaults for many properties.
Data
The Data directory contains data sets, keystores, and WSDLs that you need to run some of the examples for the LISA Demo Server.
Monitors
creditCheckValidate.tst
Test case used for CVS monitor demos. Fails randomly on a specific cid.
monitorRunBase.stg
Staging document with one user, one cycle, and 100% think time, with Pathfinder not enabled and no maximum run time.
monitorRunMultiple.stg
Staging document with one user, run continously, 136% think time, with Pathfinder enabled and a maximum run time of 15 seconds.
1.
2.
3.
monitorSLARun.stg
Staging document with one user, one cycle, and 100% think time, with Pathfinder not enabled and no maximum run time. JMX and JBOSS
metrics are selected to record.
serviceValidator.tst
Used for CVS monitor demos. Fails randomly on a specific cid.
userAddDelete.tst
This test is used in the monitor setup for CVS demos.
Setup
The Setup directory in the Examples directory contains batch files to start all LISA components, stop all LISA components, and load CVS
monitors. Because these files are not LISA assets, they do not appear in the Projects Panel listing of files.
If you want to use the stop script with access control (ACL) enabled, then you must add the user name and password options to the Service
Manager commands in the script. The password will not be automatically encrypted, so be sure to protect the file by using the appropriate method
for your operating system.
Staging Documents
1User0Think_RunContinuously
This staging doc runs a single virtual user with zero think time. It also runs the test(s) "continuously," which does not necessarily mean
"forever".
If a test being run by this staging doc has ALL of the following conditions, the run will finish when the dataset runs out of data.
There is a dataset on the first step of the test.
The dataset "End of data" step is "End the test."
The data set is "global," not "local."
If there is more than one dataset matching these conditions, then the first dataset to expire will finish the run. For a good example of this,
look at the multi-tier-combo.tst test case.
1user1cycle0think
This staging document runs a test with a single user one time with a 0% think time scale.
ip-spoofing
Use this staging document to test IP spoofing support with your LISA installation. IP spoofing is enabled in this staging document in the IP
Spoofing tab. An IP spoofing test web page is available at , if you are running the examples server.http://localhost:8080/ip-spoof-test
jboss-jmx-metrics-localhost
This staging documents runs a test with three users, run continuously, with a maximum run time of 440 seconds and 100% think time. It
has all four report generator parameter checkboxes selected, and specifies all JBOSS JMX metrics to be collected.
Run1User1Cycle
This staging document runs a test with a single user one time with 100% think time scale.
Run1User1CyclePF
This staging document runs a test with a single user one time with 100% think time scale, with Pathfinder enabled.
Run1User1CycleShowAll
This staging document runs a test with a single user one time with 100% think time scale. It also turns on all four checkboxes in the default
report generator so more things will show in the web base model execution page.
Subprocesses
ws-sec-sub
This one-step test case is marked as a subprocess and can be called from any Execute Sub Process step.
Test Suites
AllTestsSuite
The AllTestsSuite runs all the tests in the LISA Tests directory, using the 1user1cycle0think staging document and a default audit document
of AuditDocs/DefaultAudit.aud. For report metrics, it only records requests and responses, and produces the default metrics.
Test Cases
AccountControlMDB
A simple JMS test that adds a new user with an account to LisaBank. We expect and assert on patterns in the responses from the two
steps.
async-consumer-jms
An example of an "async consumer" queue where the test case continually accepts messages from a response queue/topic and makes
them available to the test case in the order that the messages came in.
The first step creates the queue (internal to the LISA test).
The second step fires three messages to a JMS queue on the demo server, which should cause three messages to be received on the
async queue.
The third step validates that three messages were received by the async queue.
ejb3EJBTest
A pure EJB test of the LisaBank functionality. Usually you would test applications by recording a web browser or other UI. Those tests are
"end to end" integration tests; these sorts of tests are "lower down the food chain" and require more technical authors (though you still do
not need to write any code!)
These tests are good for the development team to use to constantly test and validate the code without having the need for a user interface,
which may not exist at all or be changing so much that the tests cannot keep up.
ejb3WSTest
This model thoroughly tests the LisaBank web services. It is almost identical in functionality to the ejb3EJB test and useful for the same
reasons (see that test case documentation).
ip-spoofing
This example test case demonstrates IP spoofing support in LISA.
It requests the URL " " using a REST step, a web page that contains the IP address of the requestinghttp://localhost:8080/ip-spoof-test
client. It then makes a SOAP request to the URL , a web service containing anhttp://localhost:8080/itko-examples/ip-spoof-test/webservice
operation that returns the IP address of the requesting client.
It executes both requests in a loop for 10 times. You can stage this test in conjunction with the IP Spoofing Test staging document
"ip-spoofing.stg". With the correct network interface configuration, you should see different IP addresses used among virtual users as they
make the HTTP and SOAP requests.
jms
Simple JMS example showing how to send XML/text messages and objects in native Java format.
Lisa_config_info
This test case fetches diagnostic information about the computer running LISA. The results can help ITKO support solve configuration
issues.
load-csv-dataset-web
This test model uses a comma separated values (CSV) file as a data set to test a web application. The demo web app that ships with LISA
lets us add and remove users from the database.
log-watcher
This example shows how to fail a test by watching a log file for ERROR or WARNing messages.
It uses a data set to feed the example AntiPattern bean two numbers to divide. About halfway through the data set we give 0 as the
operand. This, of course, causes a divide-by-zero exception to occur on the server. The AntiPattern bean logs the exception and returns -1
as a result.
This is a common anti-pattern: internal errors occurring but external parties have no idea that the result is incorrect. It believable but itlooks
is wrong. What should happen is that the EJB propagates the exception back to the caller.
If we were using Pathfinder this test case would fail because the fact that an exception was logged will be recorded by the agent and LISA
would determine that something is wrong.
An alternative to using Pathfinder/LISA Agent is to set up a Global Assertion to watch the server log file. We define what to look for as a
regular expression: in this case simply the test "ERROR". The regular expressions can be as simple or as complicated as you want.
Usually you would set the assertion to fail the test immediately. In this case we step to the "Error detected in log file" step and end the test
normally.
Applications under test should never pass if they are logging errors or warnings. Consider using an equivalent companion in your test cases
by default.
main_all_should_fail
This test is an example of negative testing. We expect test steps to fail; that is, we feed a service data that should cause an error.
The test has a companion, the NegativeTestingCompanion, which fails the test if any steps succeed.
In this case we try to create users in the demo server that already exist. We get this data from the database itself (the username dataset
queries the table directly). If any step passes, the overall test should fail.
The only step that does pass is the "quietly succeed" step; in other words you can put steps that you do expect to fail in this sort ofnot
testing scenario but you should mark them as "quiet" in the editor so that they are not included by the NegativeTestingCompanion.
main_all_should_pass
This test calls a subprocess to insert a unique username into the demo server USERS table.
The data set is interesting in that it relies on a datasheet to draw values from a unique code generator. The same thing could have been
done with a unique code generator in conjunction with a "counter" dataset but this example demonstrates how one data set can influence
another.
Data sets are evaluated in the order they are specified; each time the step is executed, the UniqueUser property is assigned a new value
and the data sheet refers to {{UniqueUser}} four times so we get five unique values.
If any of the steps fail the test fails immediately.
Compare this test to "main_all_should_fail," which is a similar test where we expect each step to fail and we fail the test if anything passes
(this is known as negative testing).
multi-tier-combo-XML
The multi-tier-combo test uses a variety of service endpoints to validate the LisaBank example. It tests SOAP, EJB, JMS and web
transactions and validates these transactions in a variety of ways including directly validating the demo server database.
The test also demonstrates how you can build complex SOAP objects from spreadsheets. The "User" dataset on the first step is backed by
a spreadsheet named "multi-tier-users.xls" in the Data folder of the project.
If you run this test in the Interactive Test Run window (ITR) it will create a single user from the first row of the spreadsheet and then the test
will finish.
If you stage the test with the example "1User0Think_RunContinuously" staging document, the test will be restarted until the end of the data
set is reached. This is the preferred way to repeatedly iterate over a large data set. You could introduce a loop in the test case that is not as
flexible.
If you let the staging document control the data set ending the test then you can spread the test over many virtual users (if you want to) or
control the pacing of the test with think times and other parameters.
The staging document "end the continuous test run" behavior is only affected by global data sets that are set on the FIRST step in the test.
If the data set is local to the test or declared elsewhere in the test, the "run continuously" behavior really does mean "run forever".
multi-tier-combo
The multi-tier-combo test uses a variety of service endpoints to validate the LisaBank example. It tests SOAP, EJB, JMS and web
transactions and validates these transactions in a variety of ways including directly validating the demo server database.
The test also demonstrates how you can build complex SOAP objects from spreadsheets. The "User" dataset on the first step is backed by
a spreadsheet named "multi-tier-users.xl"' in the Data folder of the project.
If you run this test in the Interactive Test Run window (ITR) it will create a single user from the first row of the spreadsheet and then the test
will finish.
If you stage the test with the example "1User0Think_RunContinuously" staging document, the test will be restarted until the end of the data
set is reached. This is the preferred way to repeatedly iterate over a large data set. You could introduce a loop in the test case that is not as
flexible.
If you let the staging document control the data set ending the test then you can spread the test over many virtual users (if you want to) or
control the pacing of the test with think times and other parameters.
The staging document "end the continuous test run" behavior is only affected by global data sets that are set on the FIRST step in the test.
If the data set is local to the test or declared elsewhere in the test, the "run continuously" behavior really does mean "run forever".
rawSoap
The rawSoap step is a one-step test case demonstrating a simple raw SOAP request in the "listUsers" step.
rest-example
The rest-example test demonstrates how to execute RESTful services. The LISA Demo Server contains a JAX-RS example, and each step
in this test shows how to interact with that service using both XML and JSON.
service-validation
This is a simple example of service validation. The test calls two services (one web service, one EJB service) and validates that they do
what they claim to do by inspecting the underlying database with SQL.
web-application
This is a simple web test that was generated using the web recorder. It contains some basic assertions such as "assert non-empty
response," which is automatically generated and some "assert title" assertions that were created by parsing the HTML responses for the
<title> tag and helping to ensure the page we recorded is the same page when we play back the test.
webservices-xml
This test case will add, get, and delete a user from the EJB3 web services. It uses a unique code generator to create a number prefixed by
a value {{user}} from the config file. The password is hard-coded in the config file.
webservices-xml-fail
This test case will add, get, and delete a user from the EJB3 web services. It uses a unique code generator to create a number prefixed by
a value {{user}} from the config file. The password is hard-coded in the config file.
webservices
This test case is a very basic web service example.
ws_attachments
This test case tests our ability to send and receive inline base64 encoded data blobs and XOP/MTOM attachments. Filters and assertions
on steps verify the requests and responses look correct.
ws_security
The ws_security test case shows how to use signed and encrypted SOAP messages. The first two steps should succeed and the last two
steps should fail (the calls are the same but the web service will not accept messages that are not encrypted or signed).
Virtual Services
DatabaseModel.vsi
kioskV4ServiceImage.vsi
kioskV6.vsi
si-kioskV5-dynamic.vsi
si-kioskV5.vsi
WebAppModel.vsi
WebServicesModel.vsi
DatabaseModel.vsm
kioskV4model.vsm
kioskV5.vsm
kioskV6.vsm
1.
2.
3.
4.
statefullATM.tst
statelessATM.tst
web-app-proxy.tst
WebAppModel.vsm
webservices-vs.vsm
WebServicesModel.vsm
Creating a Project
You create a project from within LISA Workstation.
To create a project
From the main menu, select File > New > Project.
The Create New LISA Project dialog appears.
In the Project Name field, enter the name of the project.
Select one of the following options:
Create Project in LISA_HOME: Click to create a project in the project subfolder of the LISA home directory.
Create Project in a Specified Location: Click to specify the location of the project. Click Browse to browse to the directory.
Create Project from existing LISA documents directory: Click to create a new project from an existing projects file. This
option is used for importing a projects file from another directory.
Click Create. The new project appears in the Project panel.
4.
1.
2.
1.
2.
Opening a Project
When you open a project, it will have a list of folders and subfolders in the left panel.
After the project is opened, hovering on the Project icon on the left of the Project panel displays a tooltip that shows the complete project path.
To open a project from LISA Workstation
From the main menu, select File > Open > Project.
If you have already opened some projects, you will see a list of recently opened projects that you can select from. After it is selected, the
project will open.
If you want to browse for a project file, you can select File System from the list of choices and the Open Project window will open.
Select the required project and click Open.
To open a project from the command line
Navigate to the directory.LISA_HOME/bin
Run the LISA Workstation executable and specify the project directory as an argument. The project directory can be an absolute path or
2.
a relative path. The following example uses an absolute path:
LISAWorkstation C:\Lisa\Projects\Project1
Project Panel Layout
The Project panel is dockable. You can open or close the Project panel by clicking the Project button.
The Project panel contains a project tree. For a new project created from scratch, the following folders are automatically created:
MARInfos
AuditDocs
Configs
Data
StagingDocs
Subprocesses
Suites
Tests
VServices
The Project toolbar has icons to close and refresh the project, and an icon to dock or undock the Project panel.
The configuration is included by default. This configuration can be overridden by another configuration.project.config
The project has a directory, which does not appear in the Project panel. The directory is used for saving some settings.settings .settings
internally and can be seen in the file system in the Project directory.
The appears in the right panel.Quick Start window
Project Panel Right-Click Menu
You can create various documents within a project from the Project panel. When you right-click a choice in the Project panel, the menu that
appears is dynamic to the selection.
The following image includes all the available choices. The order of these choices will vary depending on what choice is selected when you
right-click.
The right-click menu choices described here are also available from the main menu by selecting File > New.
Create New Test Case: For detailed information, see .Creating Test Cases
Create New VS Model: For detailed information, see . This feature requires an additional license.Working with Virtual Service Models
Create New VS Image: For detailed information, see . This feature requires an additional license.Creating Service Images
Create New Staging Document: For detailed information, see .Building Staging Documents
Create New Suite: For detailed information, see .Building Test Suites
Create New Test Audit: For detailed information, see .Building Audit Documents
One or more of the following choices may also be available:
Add New Folder
Import Files
Rename
Delete
Paste
View/Edit Project Metadata
If you want the documents you create to default to the matching folder name, right-click that choice when adding. If you add a document without
being on that actual selection in the Project panel, it will be added to the project, but it will appear at the bottom of the Project panel list. You will
then have to go to the root directory and manually move the file into the correct folder and then reopen the project to correct.
You are not limited to keeping a certain kind of file (such as .tst) under the recommended folder (such as Tests). The file can stay anywhere within
the project. The only exceptions are .config files and data resources; they must be located in the Configs and Data folders, respectively.
Quick Start Window
The Quick Start window is the first one you will see when you open LISA Workstation.
The Quick Start window is always available as a tab after additional tabs are opened.
The Quick Start window has some of the most useful options listed within LISA Workstation. When you click an option, its parameters are listed
on the right side of the window.
The following choices are available on this window. Depending on your screen resolution, you may see the compact or the
expanded wording for each menu choice. You may need to click the down arrow at the bottom of the screen to see all menu
options.
Open Recent or Open a Recent Document
or Create a Web Services TestNew WS Test or Create a Web TestNew Web Test or Test a SOAP DocumentSend SOAP Doc
or Create a VS ModelCreate VSM or Record a WS Virtual SIRecord WS VSI or Create an SI from a WSDLVSI from WSDL
or Learn More About LISALearn More
Open Recent
When LISA Workstation opens, by default this option is selected. The right pane displays recently opened projects, test cases and suites, staging
documents, VS models or VS images (if applicable).
1.
2.
3.
4.
New WS Test
The option in the Quick Start window lets you create a Web Service test case. The parameters needed are displayed in the rightNew WS Test
pane.
Enter the WSDL URL, Service and Port details.
Check the operations that you want to test from or or select each item individually.All None
In the right pane, enter the name of the test and select the path where you would like to save it within the project folder. When you select
the path, it will be seen in the field. Within this pane, you can right-click on any folder and create a new one or rename or delete anPath
existing one.
Click the green arrow to create the test case.
For more information, see .Generating a Web Service
New Web Test
The option in the Quick Start window lets you create a web test.New Web Test
1.
2.
1.
2.
3.
4.
5.
6.
Enter the for the web test.URL
Select if you want to capture or capture .HTTP traffic Browser actions
If you select traffic, check your options in the check boxes:HTTP
HTML Responses Only: Will capture only the HTML responses.
Use External Browser: Will open an external browser window.
Configure IE for LISA: Will configure Internet Explorer for LISA.
3. In the right pane, enter the name of the test and select the path where you would like to save it in the project folder. When you select the path,
it will be seen in the Path field. Within this pane, you can right-click on any folder and create a new one or rename or delete the same as shown
previously.
4. Click the green arrow to create the test case.
For more information, see .Recording a Website
Send SOAP Doc
The option in the Quick Start window lets you create a SOAP Request test case.Send SOAP Doc
Enter the SOAP server URL and SOAP Action.
Enter the URL of the Web Service endpoint in the SOAP Server URL field.
In the SOAP Action field, enter the SOAP action as indicated in the <soap: operation> tag in the WSDL for the method being called. This
is required for SOAP 1.1 and usually required to be left blank for SOAP 1.2.
Type or paste the SOAP Request into the editor.
Enter the name of the test in the Save to field.
Click the green arrow to create the test case.
1.
2.
3.
4.
1.
2.
3.
4.
5.
Create VSM
The option in the Quick Start window lets you create a Virtual Service Model and a corresponding Virtual Service Image.Create VSM
Select the transport protocol from the list of available protocols. Your selection here will determine the next sequence of windows.
Enter the name of the Service Image.
Enter the name of the VSM and select the path where you would like to save it within the project folder. When you select the path, it will
be seen in the Path field.
Click the green arrow to go to the next screen(s).
For more detailed information about the screens and options for VSM and VSI creation, see " ."Creating Service Images
Record WS VSI
The option in the Quick Start window lets you create a web services Virtual Service Image. The parameters needed areRecord WS VSI
displayed in the right pane.
Enter a port on which to listen and record.
Enter the URL of the web service to record.
Enter the target host and port to record.
Use the SSL check box to determine whether to use SSL with this service image.
Enter the name of the VSM and SI, and click the green arrow to create the virtual service.
VSI from WSDL
The option in the Quick Start window lets you create a Virtual Service Image from a WSDL. The properties needed are displayedVSI from WSDL
in the right pane.
1.
2.
3.
4.
Enter the WSDL URL, Service and Port related details. If the WSDL URL you enter does not contain LISA properties in its path, Service
and Port will be populated automatically.
Check the operations that you want to test from or or select each item individually.All None
Enter the name of the service image and select the path where you would like to save it within the project folder.
Click the green arrow to create the service image.
Learn More
The option in the Quick Start window displays a link to LISA documentation and LISA online support information.Learn More
All available user documentation for LISA is accessible from this menu, and ITKO online support forums and issue tracking.
Tables
Tables in LISA Workstation have a consistent look and feel, and you can use the same features to customize the displays.
They all have the same banding.
They all have the ability to change their column sizes and sorting (if sortable) through a right-click menu.
Selecting Maximizing All Columns changes the Column Resize Mode to Manual.
You can also double-click on the column resizers (the column header between columns) to maximize the current column (or selected columns).
This shows the results after double-clicking the Key column resizer.
This shows the results after double-clicking the Key column resizer.
You can also click on the column header to toggle the column sort state (for sortable tables). All tables show sort indicators.
Sort Key column ascending:
Sort Value column ascending:
You may also multi-sort by holding down the Cntl key on Windows or command key on Mac. A number will show up when multiple columns are
sorted to indicate sort order.
(Value Ascending, Key Ascending)
While holding down the control/command key it will toggle between ascending and descending (skipping the reset state), but you can
control/command right-click to bring up the menu if you want to reset the sort order.
(Value Ascending, Key Descending)
All tables are banded, even ones where the rows are colored.
Some tables add additional actions in their right-click menu. The Data Sheet Dataset editor is shown, with a selection for changing the column
name.
The JDBC result set is shown in the following image.
You can use the Maximize option so the columns are all displayed, and scroll bars are available.
Color object are rendered differently in tables:
Date objects have a renderer that support smaller formats when the column shrinks.
Fullsize
Midsize (no date)
Compact (no ms)
Event Tables have a Long Info Field panel and they resize initially to maximize the first four columns and average the last two.
Tray Panels
LISA Workstation has tray panels for certain features, such as the step.Output Log Message
As of release 6.0.6, you can control whether the opening and closing of tray panels use animation. By default, animation is disabled to help
improve performance for users who access LISA Workstation through a remote desktop.
To enable the animation, add the following line to the or file:site.properties local.properties
lisa.ui.tray.animation=true
LISA Console
The web-based LISA Console provides access to the following consoles and dashboards:
Continuous Validation Service
LISA Pathfinder
Server Console
Reporting Dashboard
Continuous Validation Service
The Continuous Validation Service (CVS) lets you schedule tests and test suites to run on a regular basis over an extended time period.
For more information, see " ."Continuous Validation Service (CVS)
LISA Pathfinder
Pathfinder lets you probe into the system under test, to examine the components behind the initial request or method call.
For more information, see the .Pathfinder Guide
Server Console
1.
2.
1.
2.
3.
The Server Console enables you to manage labs and to configure role-based access control. The Server Console is also where you access the
VSE Dashboard.
For more information, see " ," " ," and " ."Cloud DevTest Labs Access Control (ACL) VSE Dashboard
Reporting Dashboard
A report viewer displays event and metric information, and information derived from data that was captured during the running of tests. You can
use a staging document to set the events and metrics that you want to capture for reporting purposes.
For more information, see " ."Reports
Opening the LISA Console
You can open the LISA Console from the main menu of LISA Workstation or from a web browser.
The home page of the LISA Console lets you access the Pathfinder Console, the Reporting Dashboard, the Continuous Validation Service, and
the Server Console. The lower right area of the home page displays the version number.
To open the LISA Console from the LISA Workstation main menu
From the main menu, select View > LISA Portal.
If access control (ACL) is enabled, then the LISA Console Login dialog appears.
Enter your user name and password and click Login.
The LISA Console appears.
To open the LISA Console from a web browser
Ensure that the is running.registry
Enter in a web browser. If the registry is located on a remote computer, then replace with the name orhttp://localhost:1505/ localhost
IP address of the computer.
If access control (ACL) is enabled, then the LISA Console Login dialog appears.
Enter your user name and password and click Login.
The LISA Console appears.
Web Server Timeouts
By default, the web server used by the LISA Console will wait 90 seconds for a process to run on the server. If a process takes longer than 90
seconds, then the connection will be aborted and the client application or browser should handle this appropriately.
You can change the default timeout value by adding the property to the file. The value is inlisa.webserver.socket.timeout local.properties
milliseconds. For example:
lisa.webserver.socket.timeout=120000
Command-Line Utilities
The following command-line utilities are included in the directory.LISA_HOME/bin
CVS Manager
CVS Manager lets you add or remove monitors to the CVS Dashboard through a command-line option. For more information, see .CVS Manager
Make Mar
Make Mar lets you show the contents of MAR info files (standalone or in an archive), or to create model archive files from MAR info files. For more
information, see .Make Mar
Service Image Manager
Service Image Manager is used to import transactions into a service image (new or existing), and to combine two or more service images
together. For more information, see .Service Image Manager
Service Manager
1.
Service Manager is used to check the status of, reset, or stop a running LISA server process. For more information, see .Service Manager
Test Runner
Test Runner is a "headless" version of LISA Workstation with the same functionality but no user interface. For more information, see .Test Runner
VSE Manager
VSE Manager is used for managing virtual service environments. For more information, see .VSE Manager Commands
Tutorials
This section contains a series of tutorials that illustrate various aspects of LISA. The tutorials are sequential and should be completed in order.
The first few tutorials walk you through using LISA Workstation to build simple test cases. You become familiar with basic concepts such as
projects, properties, data sets, filters, and assertions.
The subsequent tutorials illustrate deeper knowledge about how to set up test steps to interact with and test several common technologies,
including Java objects (POJOs), web pages, Enterprise JavaBeans (EJBs), web services, and databases. You also learn how to stage a quick
test.
Several of these tutorials use the LISA Demo Server as the system under test. You can use the Demo Server installed with LISA (locally on your
workstation), or you can reference a similarly configured demo server at .http://examples.itko.com/itko-examples/
For more information about installing the LISA Demo Server, see and .Downloading the Installer Installing the Demo Server
The following tutorials are available.
Tutorial 1 - Projects, Test Cases, and Properties
Tutorial 2 - Data Sets
Tutorial 3 - Filters and Assertions
Tutorial 4 - Manipulating Java Objects (POJOs)
Tutorial 5 - Running a Demo Server Web Application
Tutorial 6 - Testing a Website
Tutorial 7 - Testing an Enterprise JavaBean (EJB)
Tutorial 8 - Testing a Web Service
Tutorial 9 - Examining and Testing a Database
Tutorial 10 - Staging a Quick Test
Tutorial 1 - Projects, Test Cases, and Properties
In this tutorial, you will learn how to create a project and a test case. You will also look at the use of properties to understand the various places
from which they can originate.
LISA Concepts Discussed
In this tutorial, you do the following:
Create and save a new project
Create and save a new test case
Create properties
Add simple test steps
Use the Interactive Test Run utility
Prerequisites
LISA Workstation is installed and LISA license credentials are entered.
You have reviewed Basic Concepts
Steps
Step 1 - Start LISA Workstation
To start LISA Workstation:
Ensure that the registry is running. If your computer has an installation of LISA Server, then you can start the registry by clicking Start
and waiting until the LISA Registry Ready message appears. If your computer has anMenu > All Programs > LISA > Registry
1.
2.
3.
1.
2.
3.
4.
1.
2.
3.
1.
2.
3.
4.
5.
installation of LISA Workstation, you will need to use a registry that is running on another computer.
Click .Start Menu > All Programs > LISA > LISAWorkstation
When the dialog appears, select a registry and click OK.Set LISA Registry
Step 2 - Create a Project
The project that you create will hold all the test case example files that are required for the tutorials.
To create a project:
From the LISA Workstation main menu, select . The dialog appears. File > New > Project Create New LISA Project
In the Project Name field, type .My Tutorials
Accept the default setting to create the project in the directory.LISA_HOME
Click Create. The project is created.My Tutorials
Step 3 - Create a Test Case
A test case is a specification of how to test a business component in the system under test.
To create a test case:
In the Project Panel, right-click the folder and select .Tests Create New Test Case
Set the file name to .tutorial1
Click Save. LISA Workstation opens a new tab labeled . The green arrow in the model editor represents the start of the testtutorial1
case.
Step 4 - Add a Property to the Project Configuration
In this step, you set a global property in the project configuration. You will access this property later in the tutorial.
The default configuration is named , and is created automatically for a new project. The file is located in the project.config project.config
folder in the Project Panel. You can add the properties to the file and, if required, can also create a new configuration file.Configs project.config
To add a property to the project configuration:
In the Project Panel, double-click in the > folder. The properties editor for opens.project.config My Tutorials Configs project.config
Click the Add icon at the bottom of the properties editor to add a new row.
In the field, type .Key config_prop
In the field, type .Value 42
5.
1.
2.
3.
4.
1.
2.
1.
2.
3.
4.
5.
From the main toolbar, click the Save icon.
Step 5 - Add a Test Step
A test case includes one or more test steps. In this procedure, you add an Output Log Message test step to write text to the log file.
To add a test step:
Click the tab.tutorial1
Click the Add Step button , select , and select . is added to the model editor. Utilities Output Log Message Step1
Right-click and select . Change the name to .Step1 Rename Log1
Make sure that is still selected. In the right pane, click the arrow next to . The Output Log Message trayLog1 Output Log Message
opens.
Step 6 - Add a Log Message
With the log editor open, you add a log message that includes various properties.
The properties in the log message originate from several sources:
The property is automatically set.LISA_HOME
The property is a system property.java.version
You added the property to the project configuration in Step 4.config_prop
You create a new property named in the log message itself.Log1_step_prop
The syntax for a property is {{ }}.property_name
To add a log message:
In the log editor, delete the placeholder text.
Copy and paste the following text into the log editor:
The LISA home directory is: {{ }}. LISA sets this property.LISA_HOME
The value of config_prop is: {{ }}. We set this property in the configuration.config_prop
The version of Java being used is: {{ }}. This is a system property.java.version
The new value of config_prop is: {{ }}. We changed the value of config_prop here in log message itself.config_prop=21
Adding 1 to config_prop gives: {{ }} + 1. We did not change the value of config_prop.config_prop
Create a new property named Log1_step_prop: {{ }}.Log1_step_prop=100
The Log1_step_prop property has been assigned the value 100.
The log editor should look like the following image.
Step 7 - Add a Second Log Message
The second test step in the test case will write a different message to the log file.
To add a second log message:
Click the Add Step button , select , and select . is added to the model editor. Utilities Output Log Message Step1
Right-click and select . Change the name to .Step1 Rename Log2
Make sure that is still selected. In the right pane, click the arrow next to . The Output Log Message trayLog2 Output Log Message
opens.
In the log editor, delete the placeholder text.
Copy and paste the following text into the log editor:
5.
6.
1.
2.
1.
2.
1.
2.
3.
4.
The current value of config_prop is: {{ }}.config_prop
The current value of Log1_step_prop: {{ }}.Log1_step_prop
The log message does not change the values of or .config_prop Log1_step_prop
From the main application toolbar, click the Save icon, or select . File > Save
Step 8 - Run the Log1 Step
The Interactive Test Run (ITR) utility enables you to walk through and verify a test case.
To run the Log1 step:
From the toolbar, click the Start a new ITR icon . The ITR opens. The ITR contains an Execution History pane on the left and a set
of tabs on the right.
In the Execution History pane, click the Execute Next Step icon.
The step is run. The tab displays the response from the step. The properties have been replaced by actualLog1 Response Log1
values.
Step 9 - Observe Property Values
The ITR also enables you to observe how the properties are created and modified.
To observe property values:
Click the tab in the ITR.Properties
The tab displays the value of each property before and after the execution of the step.Properties Log1
A value that was created by the step is highlighted in green. A value that was modified in the step is highlighted in yellow. Notice that the
value of was changed from 42 to 21.config_prop
Compare these values with the response in Step 8.
Step 10 - Run the Log2 Step
In this procedure, you use the ITR to run the second step in the test case.
To run the Log2 step:
In the ITR, click the Execute Next Step icon to run the step.Log2
Click the tab to view the response. Even though you set to 42 in the file, you changed the valueResponse config_prop project.config
to 21 in the step, and the value did not change in the step. The value of the property also carried over fromLog1 Log2 Log1_step_prop
the step to the step.Log1 Log2
Click the tab to view the current and previous property values.Properties
When you are done, close the and tabs.tutorial1 project.config
Review
In this tutorial, you took a first look at properties. You saw that properties are denoted by using a special syntax, {{ }}. You canproperty_name
set properties by using a variation of this syntax, {{ }}. After you set a property, use or modify it in subsequent steps in aproperty_name=value
test case.
In this tutorial, you did the following:
Learned how to create and save a test case
Learned how to add a simple test step (Output Log Message)
Used a configuration to store properties
Saw a brief glimpse of the Interactive Test Run utility
Tutorial 2 - Data Sets
In this tutorial, you will learn how to create and use a simple data set. You will also learn how to provide this data set's data to a test case.
1.
2.
3.
4.
5.
1.
2.
3.
1.
2.
3.
4.
5.
LISA Concepts Discussed
In this tutorial, you do the following:
Create a simple data set
Use the data set in a variety of ways
Iterate through a series of test steps using a data set
Prerequisites
You have completed .Tutorial 1 - Projects, Test Cases, and Properties
LISA Workstation is open.
Steps
Step 1 - Create a Data Set
You will use a comma-delimited text file as the data set. This option is just one of several options available to create a data set. After you create
the text file, you import it into the project.My Tutorials
To create a data set:
In a text editor such as Notepad, create a text file. Copy and paste the following properties and values into the text editor. Do not use
spaces in the text file.
month,day,year
3,2,1956
4,7,2007
1,3,2010
5,8,{{ }}yearglobal
8,10,2004
12,11,{{ }}yearglobal
10,12,2007
3,5,2011
The first row specifies the names of the properties to which this data is assigned (month, day, year). The remaining rows specify the data
that is read and used in the test case. Two of the rows include a property named .yearglobal
Save the file as .dates.txt
In the Project panel, right-click the Data folder in the project and select Import Files.My Tutorials
Navigate to the folder where you saved the file and select the file name.dates.txt
Click Open. The file now appears in the Data folder.dates.txt
Step 2 - Create a Test Case
You will add a new test case to the project.My Tutorials
To create a test case:
In the Project panel, right-click the Tests folder and select Create New Test Case.
Set the file name to .tutorial2
Click Save.
Step 3 - Add a Property to the Project Configuration
The file includes a property named . In this procedure, you add the property to the project configuration.dates.txt yearglobal yearglobal
To add a property to the project configuration:
In the Project panel, double-click .project.config
Click the Add icon to add a new row.
In the field, enter .Key yearglobal
In the field, enter .Value 1999
Click the Save icon.
1.
2.
3.
4.
5.
6.
7.
8.
9.
1.
2.
3.
4.
5.
6.
7.
8.
1.
2.
3.
4.
1.
2.
3.
Step 4 - Add a Test Step for Output Log Message
Use a test step, the step, to write text out to the log.Output Log Message
To add a test step for Output Log Message:
Click the tab.tutorial2
Click the Add Step icon. The menu is displayed.Add step
Select and select . is added to the model editor.Utilities Output Log Message Step1
Right-click and select Rename. Change the name to .Step1 DSstep1
In the right pane, click the arrow next to . The Output Log Message tray opens.Output Log Message
Delete the placeholder text.
Enter the following log message:
Date is: {{ }}/{{ }}/{{ }}month day year
The curly brackets are important. If you do not include them, the test case will not run correctly.
Click anywhere in the model editor to close the Output Log Message tray.
Click the Save icon .
Step 5 - Create Another Output Log Message Step
Create another test step similar to the test step.DSstep1
To create another output log message step:
Click the Add Step icon. The menu is displayed.Add step
Select Utilities and select . is added to the model editor.Output Log Message Step1
Right-click and select Rename. Change the name to .Step1 DSstep2
In the right pane, click the arrow next to . The Output Log Message tray opens.Output Log Message
Delete the placeholder text.
Enter the following log message:
Date is: {{ }}/{{ }}/{{ }}month day year
Click anywhere in the model editor to close the Output Log Message tray.
Click the Save icon .
Step 6 - Execute the Test
Use the Interactive Test Run (ITR) utility to execute the test and see what happens.
To execute the test:
From the toolbar, click Start ITR. The ITR opens.
In the Execution History pane, click the Automatically execute test icon.
When the test is complete, click OK.
In the Execution History pane, click DSstep1 and DSstep2. Notice that the month, day, and year properties have not been replaced with
actual values. This result is expected, because you have not added the data set to the test case.
Step 7 - Add the Data Set
You now add the data set to the test step.dates.txt DSstep1
To add the data set:
In the model editor, select .DSstep1
In the right pane, double-click on the step element tab.Data Sets
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
Click the Add icon below the Data Sets element.
From the list, select . The data set is added to the test step. The data setCommon DataSets Read rows from a delimited data file
editor opens in the right pane.
In the data set editor, set the name to .DatesDS
Click the File Location browse button , and then navigate to and select the file in the dates.txt LISA_HOME/Projects/My
directory.Tutorials/Data
Click the Test and Keep button.
If the test is successful, the window returns a "Test successful" message.Data Set Editor
Click OK.
From the toolbar, click the Start ITR button and then select the option.Start new ITR
In the Execution History pane, click the Automatically execute test icon.
When the test is complete, click OK.
In the pane, click and . The first row of data in the data set is displayed in the tab. BothExecution History DSstep1 DSstep2 Response
step responses display the same date because we read only from the data set in .DSstep1
Step 8 - Change the Data Set Behavior
You now modify the data set so that it loops through the test step until all the rows in the data set have been read.
To change the data set behavior:
In the model editor, select the test step.DSstep1
In the step element pane of , click the arrow next to under the Data Sets element. The data set editor opens.DSstep1 DatesDS
In the field, select the option.At end of data Execute
Click the drop-down arrow on the field and select from the list of choices that appear. This setting will cause theExecute End the Test
test to end when all the data rows have been read.
Click the Test and Keep button.
Click OK to close the test successful message.
In the model editor, select the test step.DSstep2
In the element tab, set the drop-down list to . This setting will cause the two test steps to loop. TheStep Information Next DSstep1
arrows in the model editor show the order of execution: , followed by , followed by .DSstep1 DSstep2 DatesDS
From the toolbar, click the Start ITR button and then select the option.Start new ITR
In the ITR, click the Automatically execute test icon.
The test case runs in a loop until there are no more data rows in the data set.
When the test is complete, click OK.
Click the Save icon .
Review
In this tutorial, you did the following:
Created a comma-delimited data set.
Used the data set for running a simple test case.
Learned how a test step accesses the data in the data set.
Tutorial 3 - Filters and Assertions
In this tutorial, you will modify the test case created in Tutorial 2 to include a filter and an assertion.
For an introduction to filters and assertions, see .Basic Concepts
LISA Concepts Discussed
In this tutorial, you do the following:
Save an existing test case with a new name.
Add an assertion to a test step.
Add a filter to a test step.
Prerequisites
You have completed .Tutorial 2 - Data Sets
LISA Workstation is open.
Steps
1.
2.
3.
4.
1.
2.
3.
4.
1.
2.
3.
4.
Step 1 - Create a New Test Case from an Existing Test Case
In this step, you open and save it as .tutorial2.tst tutorial3.tst
To create a new test case from an existing test case:
Open the test case in the project.tutorial2.tst My Tutorials
From the menu bar, select .File > Save As
In the field, enter .File name tutorial3
Click Save. The test case is created and saved under the project.tutorial3 My Tutorials
Step 2 - Change Action of Test Step
Change the Next Steps action of both test steps so that is the next step, and only the first step reads from the data set.DSstep1
To change the action of the test step:
In the model editor, select .DSstep1
In the Step Information element tab, change the step to . With this action, the output goes back to the same step .Next DSstep1 DSStep1
For the time being, alert icons appear next to .DSStep2
In the model editor, double-click and change the Output Log Message as follows:DSstep2
Date contains 1999. It is: {{ }}/{{ }}/{{ }}.month day year
The curly brackets are very important. If they are not included, the test case will not run correctly.
Click the Save icon.
Step 3 - Add an Assertion
You can add various types of assertions to a test case. In this procedure, you will add an XML assertion named .Ensure Result Contains String
The assertion logic is as follows:
If the response contains the string , then the step will be run next.1999 DSstep2
If the response does not contain the string , then the step will be run next.1999 DSstep1
To add an assertion:
In the model editor, select .DSstep1
Open the element tab.Assertions
Click the Add icon.
From the submenu, select .XML Ensure Result Contains String
4.
5.
6.
1.
2.
3.
4.
The new assertion applied to DSstep1 is added to the tab. The assertion editor opens.Assertions
In the assertion editor, do the following:
In the field, enter .Name Test for 1999 Assertion
In the list, select .If True
In the list, select .then Go To: DSstep2
In the field, enter .Log The string 1999 was found
In the field, enter .Contains String 1999
Click the Save icon.
Step 4 - Test the Assertion
You can use the Interactive Test Run (ITR) utility to check whether the assertion works as expected.
To test the assertion:
Start a new ITR session.
In the Execution History pane, click the Automatically execute test icon.
When the test is complete, click OK.
Review the tab. Notice that when encounters a date in which the year is 1999, the test step is executedResponse DSstep1 DSstep2
next.
4.
5.
6.
Click the tab and review the behavior of the properties.Properties
Click the tab and review the events that were generated.Test Events
1.
2.
3.
4.
5.
6.
7.
1.
2.
3.
4.
5.
Step 5 - Add a Filter
You can add various types of filters to a test case. In this procedure, you add a utility filter named . This type of filter letsStore Step Response
you save the step response as a property.
To add a filter:
In the model editor, select .DSstep1
Open the element tab.Filters
Click the Add icon .
From the submenu, select . The filter editor opens.Utility Filters Store Step Response
In the filter editor, set the property name to . This property is where the step response will be stored.DSstep1_response_prop
In the model editor, double-click and add the following to the end of the output log message:DSstep2
The value of DSstep1_response_prop is: {{ }}.DSstep1_response_prop
Click the Save icon.
Step 6 - Test the Filter
You can use the Interactive Test Run (ITR) utility to check whether the filter works as expected.
To test the filter:
Start a new ITR session.
In the Execution History pane, click the Automatically execute test icon.
When the test is complete, click OK.
Review the tab. The test step now displays the additional text that you added to the output log message.Response DSstep2
Click the tab and observe where the property is created and modified.Properties DSstep1_response_prop
5.
6. Click the tab and review the events that were generated.Test Events
Review
In this tutorial, you did the following:
Took a first look at LISA filters and assertions.
Opened and modified an existing test case.
Learned how to add a simple assertion.
Learned how to add a simple filter.
Used the Interactive Test Run utility to check if the assertion and filter worked as expected.
More Information
LISA provides filters and assertions to cover most of the situations that you will encounter in your test case development. If there is not an
appropriate filter, LISA provides a mechanism, through the LISA Software Developer's Kit, for custom filters and assertions to be developed. See
the for more information.LISA Developers Guide
Tutorial 4 - Manipulating Java Objects (POJOs)
1.
2.
In this tutorial, you will create and manipulate a simple Java object and use the class to create a date object.java.util.Date
First, you construct the object and look at how to call methods on the object. Then you incorporate the object into a simple LISA model editor.
LISA Concepts Discussed
In this tutorial, you do the following:
Use the Dynamic Java Execution test step
Use the Complex Object Editor for simple objects
Use inline filters and save the results into a property
Prerequisites
You have completed .Tutorial 3 - Filters and Assertions
LISA Workstation is open.
Steps
Step 1 - Create a New Test Case
To create a new test case:
Within the project, create a new test case called .My Tutorials tutorial4
Step 2 - Create a Dynamic Java Execution Test Step
The Dynamic Java Execution test step lets you create a Java object from a class in the LISA classpath. In the following procedure, you use the
class.java.util.Date
To create a Dynamic Java Execution test step:
Click the Add Step icon. The menu is displayed.Add step
Point to and select .Java/J2EE Dynamic Java Execution
The Dynamic Java Execution editor opens.
2.
3.
4.
5.
6.
7.
In the Local JVM Settings area, ensure that is selected.Make New Object of Class
In the field to the right of , type .Make New Object of Class java.util.Date
Click Construct/Load Object. The wizard appears. The first step shows the available constructors.Complex Object Constructor
Select the constructor.Date( java.lang.Long )
Click Next and Finish. The Complex Object Editor opens.
7.
Now you have a Java object to manipulate in the Complex Object Editor.
Step 3 - Make a Call on the Java Object
The Complex Object Editor is divided into two panels. The left panel contains the , which keeps track of method invocations andObject Call Tree
their input parameters and return values. The following icons are used to identify the branches in the object call tree:
Icon Description
The type (class) of the object currently loaded, followed by response from calling 'toString' method of object.
The Constructor that was called. This is shown if multiple constructors exist.
A method call that has not been executed.
1.
2.
A method call that has been executed.
The input parameters (type and current value) for the enclosing method.
The return value (current value if call has been executed) for the enclosing method.
The contents of the right panel vary depending on what is selected in the left panel.
To make a call on the Java object:
In right panel of the Complex Object Editor, click the tab.Call Sheet
The Call Sheet tab shows the available methods that you can call.
Double-click the method. Alternately, you can select the method and click the Invoke Method icon.setYear() setYear()
2.
3.
4.
5.
6.
The method is added to the Object Call Tree. The right panel now displays the Call tab and Docs tab.setYear()
The tab lists the argument information. In the field for , enter .Call Value arg1 104
Click Execute.
In the Object Call Tree, select the object.java.util.Date
In the tab, verify that the field is now set to .Data Sheet year 104
6.
1.
2.
3.
Step 4 - Add an Inline Filter
You can add an inline filter from within the Complex Object Editor. Inline filters (and assertions) do not result in a filter being added to the test step
in the element tree. Inline filter management is always done in the Complex Object Editor.
To add an inline filter:
With the object selected, click the tab.java.util.Date Call Sheet
Invoke the method to retrieve the date to be placed in a property.toString()
The right panel now displays the Call tab and Docs tab.
In the area of the Call tab, in the field, add an inline filter by entering as the propertyStatus/Result Save Result in Property Date_prop
name.
3.
4.
5.
1.
2.
Click Execute.
Click the Save icon.
Step 5 - Verify the Property Created
You can display the Property Window to verify that the property was created.Date_prop
To verify the property created:
Click the Show model properties icon on the test case toolbar. Alternately, you can choose from theHelp > Property Window
main menu.
Locate the property.Date_prop
2.
3.
1.
2.
Click Close.
Review
In this tutorial, you did the following:
Created a test step to manipulate a Java object of type.java.util.Date
Used the Complex Object Editor to manipulate the Java object.
Learned how to add inline filters to objects and save results into a property.
Tutorial 5 - Running a Demo Server Web Application
In this tutorial, you will step through a simple web application that accompanies LISA.
The LISA Bank application is a simple front-end that is connected to a database table containing financial account information. The application
business logic consists of Enterprise JavaBeans and Web Services. From the web application, you can view the profile of the user, create an
account, add addresses, and so on.
The goal of this tutorial is for you to become familiar with the application. This application is used in subsequent tutorials as the system under test.
LISA Concepts Discussed
No new concepts are introduced.
Prerequisites
The LISA demo server is running.
Steps
Step 1 - Launch the Web Application
To launch the web application:
Open a new browser window.
Enter the following URL. Replace in the path with your computer's IP address.localhost
http://localhost:8080/lisabank/
The login page appears.
2.
1.
2.
3.
Step 2 - Log In to the Web Application
You will use the predefined user name .lisa_simpson
To log in to the web application:
In the field, enter .Name lisa_simpson
In the field, enter .Password golisa
Click Login. The welcome page appears. The left side contains buttons for various actions that you can perform: View Profile, New
, and .Account, Close Account, Add Address, Delete Address Log Out
3.
1.
2.
3.
4.
5.
Step 3 - Create a New Account
Notice that the current user does not have any accounts.
To create a new account:
Click New Account.
From the list, select .Account Type SAVINGS
In the field, enter Account Name My Savings
In the field, enter .Initial Balance 100.00
Click Add Account.
5.
The new savings account is added to the section.Accounts
5.
6. Repeat the preceding steps to create two more accounts: and . Do not use commas in the field.Checking Auto_Loan Initial Balance
6.
1.
2.
Step 4 - Close an Account
The application lets you close accounts.
To close an account:
Click Close Account.
Select from the list and click Select Account.My Savings
2.
3. Click Confirm Delete.
The account is removed from the the Accounts section.My Savings
Step 5 - Log Out of the Web Application
To log out of the web application:
Click Log Out.
Review
In this tutorial, you did the following:
Logged into the LISA Bank application.
Created new accounts.
Closed an account.
Tutorial 6 - Testing a Website
In this tutorial, you will use the LISA web recorder to record the path through a website and create test steps of HTTP/HTML Request for each
HTTP request/response pair.
The HTTP/HTML Request test step enables you to make requests against a web server and receive results from within a test case. Test a simple
website to verify that the pages work as expected.
LISA Concepts Discussed
In this tutorial, you do the following:
Use the LISA web recorder to create a test case containing HTTP/HTML Request steps
Edit and run the test case that the recorder produces
Add a data set to the test case
Prerequisites
1.
2.
3.
1.
You have completed .Tutorial 5 - Running a Demo Server Web Application
LISA Workstation is open.
You have access to the demo server (either the local demo server, or the ITKO demo server).
Tutorial Parts
Part A - Record and Run the LISABank Test Case
Part B - Running the Test Case
Part C - Modifying HTTP/HTML Request Test Steps (optional)
Part A - Record and Run the LISA Bank Test Case
Use the LISA web recorder to create a test case containing HTTP/HTML Request steps.
Step 1 - Create a New Test Case
To create a new test case:
Within the project, create a new test case named in the subfolder.My Tutorials tutorial6a Tests
The model editor is opened.
Step 2 - Start the Web Recorder
There are different ways to record a website. In this tutorial, you record a website through HTTP proxy.
To start the web recorder:
From the main menu, select . The Actions > Record Test Case for User Interface > Web Recorder (HTTP proxy) Test Recorder
dialog opens.
In the field, enter the following URL. Replace in the path with your machine IP address.Opening URL localhost
http://localhost:8080/lisabank/
Click Start Recording. The Test Recorder window opens. The Test Recorder window contains two tabs: and Browser Recorded
. The login page of the LISA Bank application appears in the Browser tab.Elements
Step 3 - Record the LISA Bank Application
As you perform actions within the LISA Bank application, the request and response information for each page visited are recorded.
To record the LISA Bank application
In the field, enter . In the field, enter .Name lisa_simpson Password golisa
1.
2.
3.
4.
Click Login.
The welcome page appears.
In the Accounts section, click the account number of the checking account. The Account Activity screen appears.
Click Deposit.
4.
5.
6. In the Deposit Money area, enter the password , a description of the transaction, and the amount for this deposit.golisa
Click Deposit.
6.
The Account Activity screen shows the updated balance and a record of the deposit.
6.
7.
1.
From the left navigation pane, click Log Out.
Step 4 - Stop the Web Recorder
After you stop recording, you can view details about the transactions.
To stop the Web recorder:
At the bottom of the Test Recorder window, click Stop Recording. Filters and properties are automatically created for the web page
references. The form fields for the deposit are also displayed. The left pane shows a list of transactions (steps). The right pane shows the
step detail and response for the selected transaction.
1.
2.
3. Click Commit Edits. The parameters page appears.
Click Add to Test and Close.
3.
4.
The model editor is populated with a new test case, having all the transaction information from the saved recording. Each test step in the
test case represents an HTTP request.
Save the test case.
Part B - Running the Test Case
1.
2.
3.
4.
In this section, continue from to run the saved test case in the Interactive Test Run (ITR) utilityPart A - Record and Run the LISA Bank Test Case
and view the results.
To run the test case,
Start a new ITR session.
In the Execution History pane, click the Automatically execute test icon.
When the test is complete, click OK.
The tab shows the rendered pages as the ITR replays the deposit into the checking account.Response > View
The tab shows the HTML code for the page captured in the step.Response > Source
LISA acts as the browser and sends the same HTTP requests to the Web server.
Close the ITR utility.
Part C - Modifying HTTP_HTML Request Test Steps (Optional)
The web recorder produces an HTTP/HTML Request test step for each request.
You can edit and modify these test steps just like the other test steps in LISA. The recorder uses the parameters that you entered during the
recording as values for the Post and Get parameters in the request.
To generalize your LISA Bank test, replace these hard-coded description and deposit amount values (for example, "cash" and "1000.00") with
properties from a data set. You previously worked with data sets in .Tutorial 2 - Data Sets
In the test step from the recording results, the and parameters are parameterized and added to theAccount Activity3 Host Name Port
configuration. The values for and are hard-coded.description amount
The objective in this part of the tutorial is to parameterize the test case to deposit different amounts of money by using a numeric counting data
set. When you subsequently run the test case, it uses deposit values different from the ones recorded.
Step 1 - Copy a Test Case
1.
2.
3.
4.
1.
2.
3.
4.
5.
6.
7.
1.
2.
3.
To copy a test case:
Ensure that the test case is open in the model editor.tutorial6a
From the menu bar, select . File > Save As
In the field, enter .File name tutorial6c
Click Save.
Step 2 - Add a Data Set
In the following procedure, you add a numeric counting data set. This type of data set enables you to assign a number to a property and change
the number by a fixed value each time the data set is used.
To add a data set:
In the model editor, select the first test step.
In the right pane, double-click the step element tab.Data Sets
Click the Add icon below the Data Sets element.
From the list, select . The data set editor opens in the right pane.Common Datasets Create a numeric counting data set
Enter the following:
In the field, enter .Name DepositsDS
In the field, select the option and select from the list.At end Execute End the Test
In the field, enter .Property Key ds_counter
In the field, enter .From 100
In the field, enter .To 105
In the field, enter .Increment 1
Click the Test and Keep button to test the data set. You will see a success message that shows the first row of data in the data set:
Click OK.
Step 3 - Modify the POST Parameters for the Recorded Deposit
You will now use the property (which you created in the data set) to specify varying amounts of money for the deposit.ds_counter
To modify the POST parameters for the recorded deposit:
In the model editor, double-click the step.LISABank - Account Activity3
In the area, change the value of the key to {{ .POST Parameters description deposit ds_counter}}
Change the value of the key to {{ .amount ds_counter}}
3.
4.
1.
2.
3.
Save the test case.
Step 4 - Stage the Test Case
To stage (or run) a Quick Test:
From the toolbar, click the Stage a quick test icon.
In the Stage Quick Test window, ensure that is selected.If test ends, restart it
3.
4.
5.
6.
1.
2.
Click OK.
The Test Monitor is displayed, but the test has not been started yet.
Click OK.
From the toolbar, click the Play icon.
The line graphs show the progress of the test.
Step 5 - View the New Deposits in LISA Bank
To view the new deposits in LISA Bank:
Log in to the LISA Bank application again with the user and password .lisa_simpson golisa
Click the account number link for checking account to view the deposits. Notice how the deposits begin with 100 and increase by 1 until
the amount 105 is reached.
2.
Review
In this tutorial, you used a numeric counting data set to provide input to the recorded test.
You did the following:
Copied a test case and added a numeric counting data set.
Modified the POST Parameters for the recorded deposit.
Staged a quick test.
Tutorial 7 - Testing an Enterprise JavaBean (EJB)
The LISA Bank application provides a full set of EJBs to interact with an account, get the user and account information from the Java interface.
In this tutorial, you will use the test step to call EJB methods within a test case and test the response with anEnterprise JavaBean Execution
assertion. You test a simple EJB to verify that the and methods work as expected.addUser deleteUser
This tutorial is currently not working. When you click the Execute icon in Step 6 - Configure the EJB, an invocation exception
occurs.
LISA Concepts Discussed
In this tutorial, you do the following:
Use the Enterprise Java Bean Execution step.
Use the Complex Object Editor with EJB objects.
Prerequisites
You have completed .Tutorial 6 - Testing a Website
LISA Workstation is open.
You have access to the demo server (either the local Demo Server, or the ITKO demo server).
Steps
Step 1 - Create a New Test Case
1.
2.
3.
1.
2.
3.
4.
5.
6.
7.
1.
2.
3.
To create a new test case,
In the Project pane, right-click the folder and select .Tests Create New Test Case
Set the file name to .tutorial7
Click Save.
Step 2 - Create a New Configuration
You previously worked with configurations in .Tutorial 2 - Data Sets
To create a new configuration,
Open the file.project.config
If the configuration does not contain the and properties, add these properties. You do not need to set the values.User Password
Create a new configuration named .config7
Add the property to the configuration and set the value to .User config7 Lisa7
Add the property to the configuration and set the value to .Password config7 Pass7
Click the Save icon.
In the Project pane, right-click the configuration and select . The configuration now appears in blue.config7 Make Active
Step 3 - Add an EJB Test Step
The Enterprise JavaBean Execution test step enables you to make calls on a running EJB.
To add an EJB test step,
Click the tab.tutorial7
Click the Add Step icon.
Select Java/J2EE and select . The New EJB Setup wizard appears.Enterprise JavaBean Execution
3.
1.
2.
3.
1.
Step 4 - Connect to the Server
The New EJB Setup wizard prompts you to specify connection information for the EJB server.
To connect to the server,
From the drop-down list, select .Select Server From List JBoss 3.2/4.0
In the field, enter if you are using the local demo server. Enter if you areHost Name or IP Address localhost examples.itko.com
running against the iTKO demo server.
Click Next.
The list of JNDI names is retrieved from the EJB server.
Step 5 - Locate the EJB Interface
The New EJB Setup wizard prompts you to specify the name of the EJB interface.
To locate the EJB interface,
In the tab, select .Remote EJB3UserControlBean/remote
1.
2. Click Next. The Complex Object Editor opens.
2.
1.
2.
3.
4.
Step 6 - Configure the EJB
To configure the EJB,
If you use the same EJB object and home object repeatedly, check the and the Keep EJB Home Reference Keep EJB Object
check boxes, if they are not already selected by default.Reference
Set the field to the step to execute if an exception occurs while executing this EJB Step. Select fromIf environment error Fail the Test
the list.
In the Object Editor area, select the tab and select the method.Call Sheet addUser
Click the Invoke Method icon.
4.
The Object Call Tree now displays the method.addUser
4.
5. Click the Execute icon.
The Object Call Tree now indicates that the method has been invoked.addUser
5.
1.
2.
3.
4.
5.
6.
Step 7 - Add an Assertion
To enter the method parameters and add an inline assertion,
In the Object Call Tree pane, check if it is not already enabled (see A).Expert Mode
Enter the property values for the method parameters (arg1 and arg2). Enter the and that you added to theaddUser User Password
configuration (see B).
In the area, add the inline assertion by checking and un-checking (see C).Status/Result Exact True
In the field, enter (see D).Comparison on Result NOT Exactly True
(The addUser method returns a Boolean.)
From the Exact list, select (see E).Fail the Test
(If the addUser method returns anything but true, it executes the step.)fail
Click Execute (see F).
6.
7.
The parameters to the method are displayed in the Object Call Tree, next to the input parameter icon. The return value of this
method is in the Object Call Tree.true
Test the method again by clicking Execute.addUser
The return changes from to because the user has already been added.true false
Step 8 - Verify the Method Execution
1.
2.
3.
1.
2.
From the LISA Bank application, you can verify that the user was added.
To verify the method execution,
Go to the LISA Bank application.
Login as user with the password .admin admin
View the list of users to confirm that was added.Lisa7
Step 9 - Add Another EJB Test Step
Now try the preceding steps again to invoke the method.deleteUser
To add another EJB test step,
Repeat the tutorial beginning with Step 3 to add an EJB step named .DeleteUser
Use the method parameter property .User
2.
3. Click Execute to execute this method and get results.
3.
4. The return is , indicating the user has been deleted.true
Click the Save icon.
Review
In this tutorial, you did the following:
Created a test case consisting of two EJB test steps. The EJB object was loaded from the example application on the demo server.
Created an EJB test step and loaded an EJB.
Used the Complex Object Editor to manipulate EJB objects.
Tutorial 8 - Testing a Web Service
In this tutorial, you will use the Web Service Execution (XML) test step to call web service operations in a test case and test the request and
response. These web service operations provide the same functionality as the equivalent method calls in the EJB used in Tutorial 7.
LISA Concepts Discussed
In this tutorial, you do the following:
Add the Web Service Execution (XML) test step.
Execute a web service operation.
Prerequisites
You have completed Tutorial 5.
LISA Workstation is open.
You have access to the demo server (either the local Demo Server, or the ITKO demo server).
Steps
Step 1 - Create a New Test Case
1.
2.
3.
4.
1.
2.
3.
4.
5.
6.
To create a new test case,
In the Project panel, right-click on the folder and select .Tests Create New Test Case
Set the file name to .tutorial8a
Click Save.
In the Project panel, right-click on and select .project.config Make active
Step 2 - Add a Web Service Execution (XML) Test Step
The Web Service Execution (XML) test step enables you to execute an operation on a SOAP-based web service. To add a Web Service
Execution (XML) test step,
Click the tab.tutorial8a
Click the Add Step icon.
Select and select . is added to the model editor.Web/Web Services Web Service Execution (XML) Step1
Right-click and select Rename. Change the name to .Step1 AddUser
Double-click the step to open the Web Service Execution (XML) editor.AddUser
Click the New Document button.
6.
1.
2.
3.
4.
5.
Step 3 - Create a Web Service Client
You now specify the operation to be called, and create a SOAP message to send to the operation. To create a web service client,
In the field, enter the following location. Notice the use of the WSSERVER and WSPORT properties to represent the serverWSDL URL
and port.
http://WSSERVER:WSPORT/itko-examples/services/UserControlService?wsdl
In the field, select .Service UserControlServiceService
In the field, select .Port UserControlService
In the field, select the operation.Operation addUser
In the field, select .On Error Abort the Test
5.
6.
1.
LISA builds the Web Service client based on this criteria. The Visual XML editor shows a graphical view of the SOAP message.
Save the test case.
Step 4 - Execute the Web Service Request
To execute the web service request,
Click the Execute WS Request icon in the upper right corner. The test is executed.
1.
2.
Step 5 - View the Request and Response
The Request tab shows the resulting request data that was sent after any post processing (for example, substituting LISA properties). The
Response tab shows the resulting response data that was received.
To view the request and response,
To view the request upon execution, click the tab.Request
To view the response upon execution, click the tab.Response
2.
Review
In this tutorial, you did the following:
Created a test case with the Web Service Execution (XML) test step.
Executed the operation.addUser
Viewed the request and response for this operation.
Tutorial 9 - Examining and Testing a Database
In this tutorial, you will examine and test a database table that is part of the web application in Tutorial 5.
You use the SQL Database Execution (JDBC) step to interact with a database within a test case and test the response with an assertion. You
examine the Users table from a Derby database that is part of the application.
LISA Concepts Discussed
In this tutorial, you do the following:
1.
2.
3.
1.
2.
3.
4.
1.
2.
3.
4.
5.
Use the SQL Database Execution (JDBC) step.
Store application properties in a configuration.
Add and modify an assertion.
Add a filter.
Prerequisites
You have completed .Tutorial 5
LISA Workstation is open.
You have access to the demo server (either the local Demo Server, or the ITKO demo server).
Steps
Step 1 - Create a New Test Case
To create a new test case,
In the Project pane, right-click on the folder and select .Tests Create New Test Case
Set the file name to .tutorial9
Click Save.
Step 2 - Add Database Properties to the Configuration
Store the properties that are needed to connect to the database in the configuration. This is a standard LISA practice that increases the portability
of test cases.
To add database properties to the configuration,
If is not the active configuration, then right-click in the Project pane and select .project.config project.config Make Active
Open the configuration.project.config
Add the following properties.
Key Value
DBDriver org.apache.derby.jdbc.ClientDriver
DBConnect jdbc:derby://localhost:1529/lisa-demo-server.db
DBUserID sa
DBPwd sa
Click the Save icon.
Step 3 - Add a SQL Database Execution (JDBC) Test Step
The SQL Database Execution (JDBC) test step enables you to connect to a database using JDBC and make SQL queries on the database. To
add a SQL Database Execution (JDBC) test step,
Click the tab.tutorial9
Click the Add Step icon.
Select and select . is added to the model editor.Other Transactions SQL Database Execution (JDBC) Step1
Right-click and select . Change the name to .Step1 Rename GetUsers
5.
1.
Double-click the step to open the step editor.GetUsers
Step 4 - Connect to the Database
Use the properties that you added to the configuration to provide connection information. To connect to the database,project.config
Enter the following values in the and areas of the step editor. Notice that when you enter the password,Connection Info Execution Info
the value is masked.
Field Value
JDBC Driver {{ }}DBDriver
Connect String {{ }}DBConnect
User ID {{ }}DBUserID
1.
2.
3.
1.
2.
3.
Password {{ }}DBPwd
Click the Test Connection button at the bottom of the step editor.
A message indicates that the connection is valid.
Click OK.
Step 5 - Execute a SQL Query
You now specify and run a SQL statement that retrieves data from the Users table. To execute a SQL query,
In the SQL Statement pane, enter the following statement:
SELECT LNAME, LOGIN FROM Users
Click the button at the bottom of the step editor. A message confirms a valid query and displays the number of rowsTest/Execute SQL
returned.
Click OK.
The tab is displayed.Result Set
3.
1.
2.
3.
Step 6 - Add an Assertion
Add an assertion to test for the presence of a specific last name in the result set. To add an assertion,
In the tab, select a cell in the column.Result Set LNAME
Click the Generate Assertion for Cell's Value icon. The dialog opens.Generate JDBC Result Set Value Assertion
From the drop-down list, select the option. If the last name that you selected is not found, then the test will fail.Fail the Test
3.
4.
5.
1.
2.
Click OK.
Click the Save icon.
Step 7 - Run the Test Case
To run the test case,
From the toolbar, click the Start ITR icon.
Click Execute Next Step . The test runs successfully. The result set is shown in the tab.Response
2.
3.
1.
2.
3.
4.
Retract the ITR tray.
Step 8 - Change the Assertion
You now modify the assertion to cause the test to fail. To change the assertion,
In the model editor, click the JDBC test step.
Open the tab in the Element Tree.Assertions
Double-click the assertion that you created earlier. The assertion editor is opened. The lower portion indicates that the assertion checks
the first column of the result set for the specified value.
Change the value of the Regular Expression field to .Johns
4.
5.
6.
1.
2.
3.
4.
5.
6.
7.
8.
1.
2.
3.
4.
Start a new ITR and run the test case again. The test fails.
Retract the ITR tray.
Step 9 - Add a Filter
Add a database filter to capture the value in the first column and fourth row of the result set. The value will be stored in a property. To add a filter,
In the model editor, select the JDBC test step.
Open the tab in the Element Tree.Filters
Click the Add icon.
From the submenu, select . The filter editor opens.Database Filters Extract Value from JDBC Result Set
In the field, enter . Alternatively, you can enter the actual column name, which is .Column 1 LNAME
In the field, enter . This field is zero-based. Therefore, the value refers to the fourth row.Row 3 3
In the field, enter .Property DBProperty
Click the Save icon.
Step 10 - Test the Filter and Assertion
To test the filter and assertion,
Start a new ITR and run the test case again.
The test fails because was not found in the result set.Johns
Click the tab.Test Events
Click the event. Notice that was set to the value specified by the filter.Property set DBProperty
Click the event. The Long Info Field area indicates that the assertion fired because the first column of the result set didAssertion fired
not contain the value .Johns
4.
5.
6. Click the tab.Properties
Locate and review the row.DBProperty
Review
In this tutorial, you created a test case to query a database. You used the Users table from the Apache Derby database that accompanies the
applications on the Demo Server. You learned how to:
Connect to the database.
Execute a SQL query against the database.
1.
2.
3.
Add assertions and filters.
Tutorial 10 - Staging a Quick Test
In this tutorial, you will use the quick staging option (quick test) to learn how to stage tests and read subsequent reports. You will run the quick test
on the example that accompanies LISA. This is the simplest way to stage a test.multi-tier-combo
LISA Concepts Discussed
In this tutorial, you do the following:
Use the multi-tier-combo test case.
Use the quick test feature.
Select and format reports.
Prerequisites
You have completed Tutorials 5 through 9.
LISA Workstation is open.
You have access to the demo server (either the local Demo Server, or the ITKO demo server).
Steps
Step 1 - Open the Test Case
We will open a test case from the examples project.
To open the test case,
From the main menu, select .File > Open > Test Case > File System
Navigate to the folder.LISA_HOME/examples/Tests
Select and click Open.multi-tier-combo
The multi-tier-combo test case opens in the model editor.
Step 2 - Review the Test Case
Take a few minutes to review the various types of test steps in this test case. For example:
Add User is a Web Service Execution (Legacy) step.
Get User is an Enterprise JavaBean Execution step.
Verify User Added is a SQL Database Execution (JDBC) step.
Deposit Money is a JMS Messaging (JNDI) step.
1.
You used many of these steps in tutorials 6 through 9. In this tutorial, you use all the test steps to build a more realistic test case involving several
layers of the application.
Part A - Running the Quick Test
Part B - Viewing the Generated Reports
Part A - Running a Quick Test
To run a quick test,
From the menu bar, click the Stage a quick test icon on the test case toolbar.
To stage a quick test, the example test case can be open in the model editor, or you can right-click on the test in the
Project panel and enter the parameters to stage a quick test from there.
1.
2.
3.
4.
In the dialog, complete the required information as follows:Stage Quick Test
Run Name: Enter a unique name ( ).Tutorial10QuickTest
Number of Instances: Enter a number of users that you want to run the test concurrently ( ).4
Stage Instances To: Select the name of the Coordinator Server or stage it locally.
If test ends, restart it: Check this option to restart the test.
Click OK.
4.
5.
6.
The Test Run window opens, but the test has not started yet.
From the main toolbar, click the Start button to start the test running.
The test begins, and the graph immediately plots results.
You can roll over the graph lines to view descriptions.
Select the tab to choose which events to display.Events
6.
1.
Part B - Viewing the Generated Reports
LISA provides a report viewer to view reports.
To view the generated reports,
From the main menu, click or click the Reports icon on the toolbar. The Report Viewer opens.View > Reporting Console
1.
2. Set the date criteria to open the graphs plotted within those dates.
In the preceding image, the graph shows that all the tests in this test case passed.
You can right-click the graph for different menus. For more information about reports, see the " " section of the .Reports User Guide
Review
In this tutorial, you tested the multi-tier-combo example using a quick test. You learned how to:
Look at a test case containing several types of test steps.
Configure and run a test in the quick test feature.
Examine a report generated from the test run.
Building Test Cases
To build test cases, you must know about setting properties, using configurations and applying them to your project, applying filters, adding
assertions, adding data sets, and adding companions. This section also introduces the Complex Object Editor.
In this section, the following topics are covered:
Anatomy of a Test Case
Properties
Configurations
Filters
Assertions
Data Sets
Companions
Complex Object Editor (COE)
Building Test Steps
Creating Test Cases
Building Subprocesses
Anatomy of a Test Case
A test case is a specification of how to test a business component in the system under test. A test case is stored as an XML document, and
contains all the information needed to test the given component or system.
A test case in LISA is a workflow with the test steps being connected by paths that represent successful and non-successful step conclusions.
may accompany the step and different paths are provided based on the firing of any of the assertions.Assertions
1.
2.
3.
Save your test cases regularly.
This section includes the following topics:
Test Case Quick Start
Multi-tier-combo Test Case
Elements of a Test Case
Elements of a Test Step
Test Case Quick Start
To start working with test cases
Start the registry. See .LISA Registry
Create or open a project in LISA Workstation. See .Project Panel
Create a test case within the project. See .Creating Test Cases
You can open an existing test case either from a valid LISA project or from outside a project by selecting File > Open > Test Case from the main
menu.
The test case is shown in the following images. For more information about the multi-tier-combo test case, see multi-tier-combo.tst .Multi-tier-combo Test Case
LISA Workstation is divided into three main areas (from left to right):
Project Panel
Model Editor
Element Panel
Project Panel
The Project panel, located in the left portion of the window, is dockable. You can open or close the Project panel by using the Project button
on the left.
When LISA Workstation first opens, the last project you had open will open by default.
For more information, see .Project Panel
Model Editor
The Model Editor is where you create and view the test case workflow. The test case workflow consists of all test steps, filters, and assertions
applied to a particular test case.
The Model Editor is the place to create and view test cases. This is the middle portion of the window and is displayed by a tab that is the name of
the test case.
The green arrow marks the start of a test case.
The workflow in the Model Editor provides a graphical view of a test case. This is very helpful as it gives a quick visual check on the test case
workflow.
In the Model Editor, each step in the test case is represented by an icon in the workflow. The icons change according to the type of test step. For
example, if you have a database-related step, a database icon and the associated filters and assertions are attached to the step.
Element Panel
The Element panel contains the elements required for a test case or a test step.
You can add or delete an element by clicking the required test case/test step element.
Some elements can be applied at the global level (to an entire test case). Some elements can be applied at a step level (only to a particular test
step).
There are some sections in which you must enter information at the beginning of a test case.
For example:
Test Case Information: Enter the test case name and check if this is a subprocess.
Documentation: Enter the documentation for the test case.
After you add steps to this test case, a workflow of steps begins to form and a new set of elements appears at a test step level in the Elements
panel.
Multi-tier-combo Test Case
The contains a test case named .examples project multi-tier-combo
This test case uses a variety of service endpoints to validate the LISA Bank demo application. It tests SOAP, EJB, JMS, and web transactions
and validates these transactions in various ways, including directly validating the demo server database.
This test case also demonstrates how to build complex SOAP objects from spreadsheets. The User data set on the first step is backed by the
spreadsheet in the Data folder of the project.multi-tier-users.xls
If you run this test in the , the test will create a single user from the first row of the spreadsheet and then willInteractive Test Run (ITR) window
finish.
If you with the example staging document, the test will be restarted until the end of the data set isstage the test 1User0Think_RunContinuously
reached. This method is the preferred way to repeatedly iterate over a large data set. You can introduce a loop in the test case, but that is not as
flexible.
If you let the staging document control the data set ending the test, then you can spread the test over many virtual users or control the pacing of
the test with think times, for example.
The staging document "end the continuous test run" behavior is affected only by global data sets that are set on the first step in the test. If the
data set is local to the test or declared elsewhere in the test, the "run continuously" behavior really does mean "run forever."
Notice the project folders being opened in the Project panel and a set of test case elements in the Element panel.example
Here you can see in the Model Editor section the test case information.
Elements of a Test Case
The elements of a test case help in building the test case as a whole. Following are the test case elements as they appear in the Test Case panel
on the right side of LISA Workstation.
Test Case Information
The tab is where you can change the name of a test case.Test Case Information
This tab is also used as an entry point for creating a subprocess, or converting a test case into a subprocess. A subprocess is a test case that is
designed to be called by another test case rather than to be run as a standalone test.
For more information about subprocesses, see .Building Subprocesses
Companions
A companion is an element that runs before and after every test case execution. Companions are used to configure global behavior in the test
case. A restart causes the companions to run again.
Double-click the companion in the Element tree to open its editor.
For more information, see .Companions
Global Assertions
An assertion is an element that runs after a step and all its filters have run, to verify that the results from running the step match expectations.
Global assertions are assertions that are applied to the entire test case.
Double-click the assertion in the Global Assertion list to open its editor.
For more information, see .Assertions
Global Filters
A filter is an element that runs before and after a test step, giving you the opportunity to change the data in the result, or store values in
properties. Global filters are filters that are applied to the entire test case.
Double-click the filter in the Global Filter list to open its editor.
For more information, see .Filters
Documentation
The Documentation text area lets you add documentation for your test case. This text is not used by LISA in any process, but it is a convenient
place: and more importantly, a good practice to put a description of your test case, and notes for other users who will use this test case.
If the test case is used as a subprocess, the documentation will be passed to the calling step.
Elements of a Test Step
A test step is an element in the LISA workflow that performs a basic action to validate a business function in the system under test. Steps can be
used to invoke portions of the system under test. These steps will typically be chained together to build workflows as test cases in the Model
Editor. From within each step, you have the ability to create filters to extract data or create assertions to validate response data.
These elements are described briefly in the following sections, and discussed in detail in .Building Test Steps
Step Information
Log Message
Assertions
Filters
Data Sets
Properties Referenced
Properties Set
Step Information
The step information section provides a place to document basic information about the test step.
You can enter the step name, think time, Execute on details, and Next step details. You can also specify to run the step using global filters and to
run the step quietly.
For more information, see .Building Test Steps
Log Message
A log message is a text field in which you can enter a message for a particular step. This message will be seen upon execution of the test step or
case.
For more information, see .Test Step Logger
Assertions
An assertion is an element that runs after a step and all its filters have run, to verify that the results from running the step match expectations. The
result of an assertion is Boolean - either true or false (there are no other possibilities).
The outcome determines whether the test step passes or fails, and the next step to run in the test case. That is, the assertion can dynamically
alter the test case workflow by introducing conditional logic (branching) into the workflow.
For more information, see .Assertions
Filters
A filter is an element that runs before and after a test step, giving you the opportunity to change the data in the result, or store values in
properties.
For more information, see .Filters
Data Sets
A data set is a collection of values that can be used to set properties in a test case while a test is running. This provides a mechanism to introduce
external test data to a test case.
For more information, see .Data Sets
Properties Referenced
This section contains a list of properties used or referenced by the test step.
Select and right-click the property to open the extended view and get its variable value.
For more information, see .Properties
Properties Set
This section contains a list of properties set by the test step. The Properties Referenced and Set are for a particular step and will change when
another step is highlighted.
For more information, see .Properties
Properties
Test properties are name–value pairs, also known as key–value pairs.
The key to data independence, reusability, and portability in test cases is the ability to abstract specific data values out of the test case and
replace them with variables. These variables are referred to as . Some properties are predefined and guide how LISA operates. Otherproperties
properties are created by you while you are building your tests.
Properties are both ubiquitous and indispensable in test cases. A sound understanding of properties is vital to the creation of test cases. In the
context of a test case, any time there is something that can change, it is appropriate to use a property. This includes values in test steps and
values in configurations, for example.
Properties can be defined in several ways. After they are defined, they are available to any subsequent steps, assertions, and filters in the test
case (they are global to the test case). Properties can, with few exceptions, be overridden in a test case.
Whenever a property value is set, an event is recorded that contains the property name and value.EVENT_SETPROP
Property values are not limited to string values. A property can hold strings, numbers, XML fragments, serialized Java objects, or the complete
response from a test step. Many properties are created during a test run that are available to the subsequent test steps. For example, the
property contains the response for the step.lisa.stepname.rsp stepname
In this section, the following topics are covered:
Specifying a Property
Property Expressions
String Patterns
LISA Property Sources
Property Files
Common LISA Properties and Environment Variables
Specifying a Property
The syntax for a property is .{{property_name}}
When a property is identified and about to be used, is replaced by its current value. There are times when a property is{{property_name}}
expected, and is the only choice. Other times, you are asked for the property name explicitly. In these cases, you enter the property name without
the braces. When properties are embedded in a text string, you must use the brace notation. There is an additional syntax that allows property
to be used: or .expressions {{=expression}} {{property_name=expression}}
A property name can contain spaces. However, using spaces is not recommended. The characters that define the property syntax ( , , and ){ } =
cannot be used.
All property names that start with are reserved for internal use. Properties that start with may be hidden or deletedlisa. lisa .
If you reference a property that does not exist, the property is left in the braces to indicate that the property was not found, or it is invalid.
Property Expressions
LISA properties can store many different types of data. They can also evaluate and store expressions. These expressions can contain any valid
Java or JavaScript expressions that can be evaluated by BeanShell. BeanShell is a Java interpreter environment. Further, these expressions
could be string patterns, which give real-looking fake strings, appropriate for most given purposes.
For more information about BeanShell, see or .Using BeanShell in LISA www.beanshell.org
To use a property expression, you use the syntax or . In the first case, , BeanShell will{{ }}=expression {{ }}key=expression {{ }}expression
be used to evaluate the expression and replace by the result of the evaluation. For example, will evaluate{{ }}expression {{ }}=Math.random()
the static Java method and replace the construct with the random number that was returned. In the latter case, using {{}} {{
will set a property equal to the random number that was returned, in addition to replacing the construct with}}rand=Math.random() rand {{}}
the random number.
Existing properties can be used in a property expression. They are referenced by name only, that is, without the braces, because they are already
defined as properties. If the property is not found, the property expression is returned within braces, to indicate that there is a problem in the
expression.
String Patterns
String patterns are special types of property expressions that have a syntax For example, to format a first name, the string{{ =[:patternname:] }}.
pattern property could be . The property would evaluate to a fake first name that looks like a real name.{{ =[:First Name:] }}
This is much better than the possibility of dealing with random strings that do not look like a real name. Of course, the string pattern functionality
supports many patterns in addition to first names: last names, dates, Social Security numbers, credit card numbers, credit card expiration dates,
and many more. This fake data comes with LISA, in TESTDATA table in its reportdb database.
The recommendation is that if you need a first name in your test case, you use {{ =[:First Name:] }} in a data set. The "{{=[ " part is a signal to use
the string pattern and it has a list of things "registered" that it knows about.
As an example, if you put the following information in a log step:
{{ =[:First Name:]}} {{ =[:Middle Initial:] }} {{ =[:Last Name:] }}
{{ =[:Street Address:] }}
{{ =[:City:] }}, {{ =[:State Code:] }}
{{ =[:ZIP Code:] }} {{= [:Country:] }}
SSN: {{ =[:SSN: DDD-DD-DDDD] }}
Card: {{ =[:Credit Card:] }} Expires {{= [:CC Expiry:] }}
Phone: {{ =[:Telephone:] }}
Email: {{ =[:Email:] }}
You get the response:
Marilyn Mcguire
3071 Bailey Drive
Oelwein, IA
50662 US
SSN: 483-16-8190
Card: 4716-2361-6304-6128 Expires 3/2014
Phone: 319-283-0064
Email: Marilyn.C.Mcguire@spambob.com
If you run the step again you will get a different set of data. It will keep track of the number of rows in the test data database and randomly select a
row between 1 and N.
Select Help > Property Window > Patterns to open the following screen, which shows all existing string patterns and shows the
documentation.
Implementation Information
The data is stored by default in the reports database in the TESTDATA table.
When LISA Workstation is started, it checks to see if there is any data there and if there is no data, then com/itko/lisa/test/data/TestData.csv
inside lisa-core.jar is read to load up the database. If reports.db gets deleted for some reason, the test data will be recreated. Reading the
database is done only at startup and takes about 15 seconds.
Creating your own String Pattern
To add your own data, the only thing to be careful about is to assign the ID correctly. Start with 1 and increase with no gaps until you get to your
number of rows.
The string generator code essentially does after getting from a random object. So, ID must be the primaryselect * from testdata where id = 'n' n
key of the table to help ensure efficient lookups.
Example
A good way to get some practice with property expressions is to build a simple test case that has a single step: an Output Log Message. Because
this step just writes to a log, and displays its response in the Interactive Test Run (ITR) Response Panel, you can experiment with using property
expressions.
The following example uses the multi-tier-combo test case in the examples directory (multi-tier-combo.tst).
This illustration shows our example in the LISA ITR utility.
These illustrations show the Properties tab in the ITR. This is for the step Get User.
This illustration shows the Test Events tabs in the ITR.
1.
2.
Look for the event Properties set in the Test Events tab.
Java developers can also take advantage of the BeanShell environment in the JavaScript step to test property expressions.
LISA Property Sources
Properties can originate from several sources that include:
LISA
Environmental variables
Command line variables on startup
Configurations
Companions
Test steps
Filters
Data sets
String patterns
Because properties can be overridden, it is important to understand the property hierarchy, or the order in which properties are read in a test
case.
The following hierarchy is used:
Properties loaded during the set up of a test
2.
3.
4.
5.
6.
7.
8.
9.
Operating system environment variables (like java.version or os.user, for example)
LISA property files
Command line attributes
The default configuration
Any alternative configuration properties (from active configuration or runtime configuration file)
Properties set during a test run
Properties in companions
Properties set during test execution (for example, in data sets, filters and steps). Remember that properties set here override values set
earlier.
Common LISA Properties and Environment Variables
HOT_DEPLOY: Points to a project-specific directory.hotDeploy
LASTRESPONSE: The response to the last executed step.
LISA_HOME: Points to the LISA install directory, and is automatically set. This value includes a final slash. To reference a directory such as
"examples", specify:
{{LISA_HOME}}examples
No slash is needed before the directory name.
LISA_HOST: The name of the system on which the testing environment is running.
LISA_JAVA_HOME: The Java VM that LISA will use. Use this only if you do not want to use the built-in VM in LISA. If there is no Java installed,
LISA uses the bundled JRE it comes with. You also must rename the directory in the LISA install directory to something like .jre jre_notinuse
LISA_POST_CLASSPATH: Used to add information after the LISA classpath. LISA does not use the OS environment CLASSPATH variable. To
add your own JARs after the LISA classpath, use LISA_POST_CLASSPATH.
LISA_PRE_CLASSPATH: Used to add information before the LISA classpath. LISA does not use the OS environment CLASSPATH variable. To
add your own JARs before the LISA classpath, use LISA_PRE_CLASSPATH.
LISA_PROJ_NAME: The name of the project to which the current document belongs.
LISA_PROJ_PATH: The fully qualified path of the project directory. The value is operating system-dependent. A backslash (\) is used as the
separator character on Windows. A forward slash (/) is used as the separator character on all other operating systems. The following example is
based on a Windows installation:
C:\Program Files\LISA\examples
There is one limitation to using LISA_PROJ_PATH in a Custom Java step: the syntax {{LISA_PROJ_PATH}} is not supported. Because the
Custom Java step invokes a Java compiler to compile the script, and Java treats backslashes as escape characters in strings, this particular
string raises a compiler error. The workaround is to use LISA_PROJ_PATH as a variable. For example:
File f = new File ( LISA_PROJ_PATH );
LISA_PROJ_ROOT: The fully qualified path of the project directory. The value is operating system-independent. A forward slash (/) is used as
the separator character on all operating systems, including Windows. The following example is based on a Windows installation:
C:/Program Files/LISA/examples
LISA_PROJ_URL: The URL of the project directory. For example:
file:/C:/Program%20Files/LISA/examples
LISA_TC_PATH: The fully qualified path of the directory where the test case is located.
LISA_TC_URL: The URL of the directory where the test case is located.
LISA_USER: The user that loaded the test case.
Property Files
The main property files are:
lisa.properties file
local.properties file
site.properties file
Detailed information about properties is available in these appendixes:
Appendix A - LISA Property File (lisa.properties)
Appendix B - Custom Property Files (local.properties, site.properties)
Configurations
A configuration is a named collection of properties that usually specify environment-specific values for the system under test.
By removing hard-coded environment data from the test case, you can run the same test against different environments by simply using a
different configuration. Configurations are used everywhere within LISA: for example, in a test case document, test suite document, staging
document, test case execution or test suite execution.
A configuration must be defined at the LISA project level. You can specify the values of these properties at the beginning of a test case.
The default configuration of any project is . You can create additional new configurations within a project and "Make it Active" for aproject.config
particular test case/suite.
If you create a new config file, you will be able to add any new keys within it. To add keys within the new config, you must add them in the not
file. You can then select the newly-defined keys added in the file from the drop-down available in the new configproject.config project.config
file.
Properties are added to your configuration automatically as you develop your test.
For example, in a web service test when you enter the name of the WSDL, the server name and the port that you entered are replaced with
properties such as and The values of these properties are automatically added to your default project configuration. Now youWSSERVER WSPORT.
can change the location of the web service merely by editing the configuration, rather than looking for hard-coded values in several test steps.
In another example, when working with Enterprise JavaBeans (EJBs) or Java objects, you may want to switch hot deploy directories, or add extra
JAR files to your class path, to use different versions of your Java code. There are standard properties for these locations: HOT_DEPLOY and
MORE_JARS. These can be set in your configuration.
For information about other standard properties, see .Properties
Configurations are for storing properties related to the system under test. Avoid using them for storage of "test-like" parameters and global
parameters. These can be stored in a .companion
Backslashes "\" are not preserved in configuration files. If you edit the config file manually and put something that has a
backslash, the file will be overwritten without the backslashes.
The following topics are available in this chapter:
LISA Project Configuration
Default Configuration
Adding a Configuration
Marking a Configuration as Active
Editing a Configuration
Copying a Configuration
Deleting a Configuration
Renaming a Configuration
Creating a New Configuration File
Importing a Configuration File
Applying a Configuration when Running a Test Case
LISA Project Configuration
1.
2.
The configuration at the project level can be seen in the section in the Project panel.Configs
The project.config is by default the active configuration (marked in green) for any LISA project.
All newly-defined properties must be in the default project.config file. Later they can be pulled into the new configuration file.
New configurations can be applied to a test case by making them " ".Active
Configurations are defined at the project level.
Default Configuration
The default configuration of any project is . It is also the configuration for the project. It has the superset of all the keysproject.config active
defined in every other configuration.
After you open a project, the default configuration ( ) is shown in green in the Configs folder.project.config
You cannot delete or rename the default configuration.
You can change the active configuration of a project. For instructions on how to do this, see .Marking a Configuration as Active
Double-clicking will open the configuration in the Properties Editor window. The name of the tab will show the name of theproject.config
configuration.
These are standard LISA config parameters that are available in all configurations.
To add parameters in other configurations, first add them here and then select from the drop-down in the required configuration.
Adding a Configuration
A project can have many alternate configurations, but it can have only one active configuration. Any alternate configuration or the default
configuration can be made active. Alternate configurations can only override default properties.
To add a configuration
Right-click the folder in the Project panel.Configs
2.
3.
4.
1.
2.
1.
Click Create New Config.
Enter the name of the new configuration.
Click OK.
Adding Key-Value Pairs
To add keys within the new configuration, you must add them in the file. You can select the newly defined keys from theproject.config
drop-down in the new configuration file. In a new configuration file, you will be able to add any new keys.not
When you create a configuration file, the only keys that you can add are the ones that are already defined in , in addition to theproject.config
standard config keys provided with LISA.
Marking a Configuration as Active
When you want to apply a different configuration to your project, you must make it active.
Within the Configs folder, you can mark any configuration as active.
To mark a configuration as active
Right-click the required config file in the Configs folder.
Click Make Active.
A configuration can be both the default and active.
The active configuration applies to the whole project, not a single test case.
Each test case in a single project shares the active configuration applied to the project. You cannot assign a separate configuration for each test
case within a project.
The active configuration takes precedence in the Interactive Test Run (ITR) utility, but the default configuration is used in a if noStage Test Case
configuration is specified.
Editing a Configuration
In any configuration other than , you can add properties only if they exist in .project.config project.config
A best practice is to use properties in the path names stored in the configuration. Properties such as or will allowLISA_HOME LISA_PROJ_ROOT
for portability of test cases.
A property value can contain multiple lines.
The extended view consists of a dialog for editing a property value. This view can be useful when the value is long or when the value contains
multiple lines. To access the extended view, right-click the property value cell and select Launch Extended View.
To edit a configuration
Double-click the configuration in the folder. The Properties Editor appears.Config
1.
2. You can add a property by clicking the Add icon at the bottom of the Properties Editor. A new line is added to the property list. Click
the drop-down to select the chosen key. Common property names, such as HOT_DEPLOY and MORE_JARS, appear in the drop-down.
2.
1.
2.
1.
2.
Copying a Configuration
To copy a configuration
Select the configuration file to be copied, right-click and select Copy to copy the selected configuration.
To paste a configuration
Click the Configs folder, right-click and click Paste. You will be prompted to rename the pasted config because it will appear to be a
duplicate of the copied config.
Rename the configuration file and click OK to add the new configuration in the Config folder.
Deleting a Configuration
To delete a configuration
Select the configuration to be deleted and right-click.
Click Delete from the dialog.
1.
2.
3.
1.
2.
3.
4.
5.
1.
You cannot delete the default configuration (project.config).
Renaming a Configuration
To rename a configuration
Select the configuration and right-click to open a menu.
Click Rename to rename the configuration.
In the window that opens, enter the new name and click OK to rename the file.
You cannot rename the default configuration (project.config) within LISA. When right-clicking on project.config, the Rename option will not appear.
Creating a New Configuration File
You may need to create a new configuration file to import into LISA.
A configuration file is a text file with a .config extension that contains the properties as key-value pairs. All configuration files are an integral part of
any test run.
Configuration files can be created, or edited in any text editor and can be saved with a config extension..
When starting a test run, you will have the opportunity to choose a configuration file of your choice. There is an example of this later in this
chapter.
We recommend that you establish a naming convention for configuration files, making identification of alternate configurations easier.
These configuration files need to be into LISA.imported
Importing a Configuration File
To import a configuration file
Select the Configs folder and right-click to open a menu.
Click Import to import a configuration file.
On the window that opens, enter the name of the configuration file to be imported and click Open to import the file.
A notification message appears explaining that a config file is being imported and a successful message also appears.
Click OK.
You will see the new configuration file imported in the list of configurations, and any new properties will also be added to .project.config
Applying a Configuration when Running a Test Case
Running a test case is one of several places where configurations are used.
To start a test case execution, you must give the test case details with the configuration to be applied.
To stage/start a test case from the main menu
Select Actions > Stage Test. The Stage Test Case dialog appears.
1.
2.
3.
4.
The Configuration pull-down will include all the configurations defined in the project. Assigning a configuration file here is optional. If
omitted, the default configuration in the test case document will be used.
Select the staging document to refer to while executing the test case.
Select the coordinator server.
When your selections are complete, you can either click Stage to stage the test, or Save as MAR... to create a model archive including
the test case, configuration, staging document and coordinator server information you specified here.
Filters
A filter is a LISA code element that runs before and after a test step, giving you the opportunity to change the data in the result, or store values in
properties.
Most filters execute after the step has run. A filter can be used to extract a value from a web page, XML and DOM responses, a Java object, a
text document, and many other test step responses.
After the data has been filtered, the data can be used in an assertion, or in any subsequent test step. Filters usually operate on the response of
the system under test. For example, filters are used to parse values from an HTML page, or to perform conversions on the response. Filters can
also be useful in other places; for example, to save a property value to a file, or convert a property to be the "last response".
There are two basic ways to apply a filter, as a or as a . The available filter types are the same, but how the filters areglobal filter step filter
applied differs.
Global filter: A filter defined on the level is a global filter, and executes before/after every test step that is not set to ignoretest case
global filters. You can set a step to ignore global filters in the Step Information Element of the step.
Step filter: A filter defined on a level is a step filter and executes before/after each execution of that test step.test step
You can add as many global and step filters as you need. They are executed in the order that they appear in the test case.
Filters are mainly used as property setters.
The following topics are available in this chapter.
Adding a Filter
Deleting a Filter
Reordering a Filter
Dragging and Dropping a Filter
Types of Filters
Adding a Filter
There are several ways to add filters.
Adding a Filter Manually
Adding a Filter from an HTTP Response
Adding a Filter from a JDBC Result Set
Adding a Filter from a Returned Java Object
Adding a Filter Manually
To add a filter manually, select the filter type from a list and enter the parameters for the filter.
You can add two types of filters manually: global filters and step filters.
The first method lets you add a filter at the test case level (global filter). Global filters are applicable to all the steps in the test case and are
1.
2.
3.
1.
2.
automatically run for every step in the test case, unless a given step is instructed otherwise.
The second method lets you add a filter at the test step level (step filter). A filter created using this method is applicable only to that step and will
execute for that step only.
Add a Global Filter
Open a test case and click anywhere in the editor area to open the Test Case Elements panel.
On the Global Filters element, click the Add icon to add a global filter. You will be prompted to select a filter type of LISA Integration
Support for Pathfinder or LISA Integration Support for webMethods Integration Server. For more information about adding each of these
types of filters, go to or .LISA Integration Support for Pathfinder LISA Integration Support for webMethods Integration Server
When you have at least one global filter on a test case, you can see that for each step, by default the Use Global Filters check box is
selected. If you do not want to apply a global filter for a particular step, clear the box.
Add a Step Filter
Select the step for which you want to apply the filter and in the right panel, click the Filter element.
Click the Add icon of the filter element to get the list of available filters to choose from, or right-click the step and select Add Filter
and select the appropriate filter for this step.
This will open the Filter menu listing the common filters in LISA. Each filter has its own editor and applicable parameters that need to be set.
Example
This example uses the Override Last Response Property/Convert Property Value into Last Response filter.
This filter converts a property value into the last response.
To configure the filter, enter the following parameters:
Filter in (Property to Convert): The name of the property you want considered as the step's last response. The property should be in
the pull-down menu. You can type the property name if you do not find it there. The filter will give an error if it is not an existing property.
Convert to XML: Select this if you want the response to be converted to valid XML.
Run Filter: Click to run the filter.
Adding a Filter from an HTTP Response
When you have access to the response from an HTTP-based step, you can use the response to add a filter directly.
1.
2.
This example uses the response of the login step in the multi-tier-combo test case in the examples directory (multi-tier-combo.tst). The point of
this example is to capture the text where currently appears on the screen. (It will not always be the same text).MyMoney Home
Run the multi-tier-combo test case in the ITR, then select the Login test step.
Select the text in the View tab and click the DOM Tree tab to make sure that this text is selected in the tree view.MyMoney Home
2.
3. To apply an inline filter, double-click the login step in the model editor to open the HTTP/HTML Step Editor.
3.
4.
5.
6.
7.
Move to the DOM Tree tab, find in the DOM Tree view, and select it.MyMoney Home
At the bottom of the screen, in the Select a Command box, select Parse Value Filter from the drop-down menu.
In the dialog window that is displayed, enter the name for the Property Key "wasAdded":
Click OK.
1.
2.
You can also add an assertion here. For example, you would probably want to test the value of the property "wasAdded," to see if it is in fact
equal to Added user. More information is available in .Adding Assertions
The filter that was generated can be seen as a filter in the login test step.
The same filtering capabilities are available when an HTML response is displayed in the step editor.
Adding a Filter from a JDBC Result Set
When you have access to the result set response from a JDBC step, you can use the response to add a filter directly.
Here is an example of the JDBC Result Set response, using the response of the Verify User Added step in the multi-tier-combo test case in the
examples directory (multi-tier-combo.tst).
Double-click the Verify User Added step to open its step editor.
Edit the SQL statement to read and click the Test/Execute SQL button to get values in the result set.Select * from users
2.
3. Click the Result Set tab and click the Test/Execute SQL button to get values in the result set.
3.
4.
5.
6.
Click the cell in the result set tab that represents the location of the information you want to capture ( ).sbellum
Click the Generate Filter for Current Col/Row Value icon .
In the dialog that opens, enter the property key .theLogin
6.
7.
8. Click OK. LISA will add a filter named Parse Result Set for Value in the list user step.
Click the filter editor to see the filter.
In the example, the value in the cell in the 1 column, and 2 row, , will be stored in the property theLogin.
st nd sbellum
Applying a Second Filter
There is a second filter that can be applied here. You can look for a value in one column of the result set, and then capture a value from another
column in the same row.
From within the result set, select the two values in two different columns from the same row, using the Ctrl key.
1.
2.
3.
Select Filter for a value and then get another column value filter using the icon. Select two cells in the same row to create this filter.
One will be the search column and the other will be the column whose value you want to extract.
In the dialog that opens, check or reassign the columns for the search and the value, then enter the property key .theEmail
Click OK. LISA will add a filter named in the Verify User Added step.Get Value For Another Value in a ResultSet Row
1.
2.
This filter looks for in the LOGIN column, and if found, stores the value in the EMAIL column in the same row in a property named sbellum
.theEmail
The same filtering capabilities are available when a JDBC result set is displayed in the Step Editor.
Adding a Filter from a Returned Java Object
When the result of your test step is a Java object, you can use the Inline Filter panel in the Complex Object Editor to filter the returned value from
the method call directly. Following is an example of how to add a filter this way.
This example uses the get user step (EJB step) in the multi-tier-combo test case in the examples directory.
Double-click the get user step in the workflow, to open its step editor.
Click Next. On the next screen, click Finish.
2.
3.
4.
5.
Click Show Editor to open the Object Call Tree.
Enter an input parameter "itko" in the value field.
Click Execute to execute this method.
1.
2.
1.
2.
3.
The returned value upon executing the getLogin method will be stored in the property getUserObject. Notice that in this case the returned value is
an object (of type UserState). You also can add an assertion here.
In this example, you could also call a method on the returned object to get the actual login value for this user, and save the login in another
property.
Inline filters (and assertions) do not result in a filter being added to the test step in the element tree. Inline filter management is
always done in the Complex Object Editor.
For more details on the Complex Object Editor, see .Using Complex Object Editor
Deleting a Filter
To delete a filter
Select the filter in the Filter Elements tab and right-click to open a menu. Click Delete to delete the filter. Or,
Select the filter in the Filter Elements tab and click the Delete icon on the toolbar.
You cannot delete a test step that has filters attached to it.
Reordering a Filter
To reorder a filter
Select the filter in the Filter Elements tab.
Click the Move up or Move down icon on the toolbar.
Dragging and Dropping a Filter
You can drag and drop filters in the model editor from one test step to another.
To drag and drop a filter
Click the filter attached to a test step; for example, Step1.
Drag and drop that filter to another test step in the model editor; for example, Step2.
The dragged filter will then be applied to Step2.
Types of Filters
This section describes each of the filters that are available in LISA.
Regular expressions are used for comparison purposes in several filters. For more information about regular expressions, see
.http://psoug.org/reference/regexp.html
The following filters are available.
Utility Filters
Database Filters
Messaging_ESB Filters
HTTP_HTML Filters
XML Filters
Web 2.0 Filters
Java Filters
VSE Filters
Pathfinder Filters
Utility Filters
These are the filters available in the Utility Filters list for any test step.
Create Property Based on Surrounding Values
Store Step Response
Override "Last Response" Property
Save Property Value to File
Parse Property Value as Argument String
Save Property from one key to another
Time Stamp Filter
Create Property Based on Surrounding Values
The filter lets you read textual content and filter it for information to be stored in LISACreate Property Based on Surrounding Values
properties. It can be used on text, and on XML and HTML treated as text. It uses a "paint the screen" technique.
"Paint the screen" gives you great flexibility to define what in the text buffer you want to parse out as properties. There are three ways to mark the
text:
Text that must appear in the response precisely as shown: a block.Must
Text that does not have to appear in the response, or can change: an block.Any
Text that will be stored in a LISA property: a block. Property blocks must always be bounded by blocks.Property Must
The text is marked using the icons at the bottom of the editor:
This technique is best explained by example.
In the following example, the goal is to store the size of a particular file in a property.
The text is marked using the editor icons, by selecting text and then clicking the appropriate icon.
Yellow background indicates text that must appear as shown (indicated by the arrows from "Text uses ........." ). This is a block andMust
is marked using the icon.Must
Red background identifies the text that will be stored in the property entered into the dialog (indicated by a single arrow). This is a
block and is marked using the icon.Property Property
Property blocks must always be bounded by blocks.Must
This screen shows the contents of the text buffer. The goal is to parse out the file size of the Simulator.exe file. The file size is the number that
appears after "Simulator.exe". The boundaries are set around the file size, and the icon has been clicked. The actual file size textMust
inside the selected content was selected, and the icon was clicked. The property name was then entered into the dialog. The actualProperty
value of the file size has been replaced with the name of the LISA property.
When this filter is run, the property "filesize" will be assigned the size of the Simulator.exe file.
You can repeat this process on this text buffer to have as many properties defined as you like.
Handling Non-unique Tokens
If you see the following error message, your selected token is not unique; the selection you just made is repeated in the token before it.
To solve this in most cases, simply create another token to make the prior token a token also. In other cases, when this does not work, aMust
judicious placement of another block between the two duplicate tokens will avoid the error. This will work because LISA can distinguishMust
between the two duplicate tokens based on their relative location.
Store Step Response
(Also known as Save Step Response as Property)
The filter lets you save the last response as a property, for future use.Store Step Response
Enter the following parameters:
Filter in: Where to apply the filter. The previous illustration shows list.Add User.rsp, which means that the filter will be applied to the
response of the Add User step. You cannot change this value for this filter.
Property: The name of the property to store the last response.
Filter Run Results: Displays the property and values set as a result of running the filter.
Click the Run Filter button to execute the filter and see the results in the Filter Run Results.
Override "Last Response" Property
(Also known as Convert Property Value into Last Response)
The filter lets you replace the current value of the last response with the value of an existing LISA property.Override "Last Response" Property
For example, assume you execute an EJB, but you eventually get a value back after making some method calls on the EJB. Instead of leaving
the EJB object to be the last response, it may make more sense, in your test case, to make the result from one of your method calls the last
response. You can first save the return value from that call as a property using a filter, and then you can use that property in this filter.
Enter the following parameters:
Filter in: The name of the property you want considered as the step's last response. The property should be in the pull-down menu; if not
you can enter it. It must be an existing property.
Convert to XML: Select this if you want the response to be converted to valid XML.
Filter Run Results: Displays the property and values set as a result of running the filter.
Click the Run Filter button to execute the filter and see the results in the Filter Run Results.
Save Property Value to File
The filter lets you save the value of an existing property to a file in your file system.Save Property Value to File
Enter the following parameters:
Filter in: The name of the property whose value you want to write to the file.
Location: The path name of the file to write the value to. You can browse to the file. You can use properties in the location.
Append Mode: Select this check box if you want to append the information to an existing file.
Filter Run Results: Displays the property and values set as a result of running the filter.
Click the Run Filter button to execute the filter and see the results in the Filter Run Results.
Parse Property Value as Argument String
The filter lets you store the text of a specific attribute in a property. This is very useful as a secondParse Property Value As Argument String
filter, where you parse a filtered value for information.
Enter the following parameters:
Filter in: The name of the existing property to parse. For example, to parse the "lisa.deleteUser.cookies.rsp" property to return the value
of the SESSIONID attribute, enter .lisa.deleteUser.cookies.rsp
IsURL: Select this check box if the property value is a URL.
Attribute: The attribute to retrieve. The example shows the JSESSIONID attribute.
Property: The name of the property to store the text of the attribute. The example shows .sessionID
Default (if not found): The default value to use if the attribute is not found.
Filter Run Results: Displays the property and values set as a result of running the filter.
Click the Run Filter button to execute the filter and see the results in the Filter Run Results.
Save Property from one key to another
The filter copies values from one key to another by reference where normal Java rules apply.Save Property from one key to another
This filter simply optimizes BeanShell overhead for simple property copy.
Enter the following parameters:
Filter in: This field accepts the property content of which will be copied in some other property. This is the input source property.
To Property: This is the property name where input property content will be copied.
Run Filter: Lets you test the filter immediately while developing test steps rather than waiting until the test case is completed.
Time Stamp Filter
The filter is used to assign the current time and date to the property so that you can use this property in the following test steps.Time Stamp
Enter the following parameters:
Filter in: The name of the existing step.
Date Pattern: Select the date pattern you want to display.
Offset: Used to offset the date to an appropriate (future or past) date based on the current date.
Pre Process: When enabled, generates a time stamp before the step runs.
Property for Pre Process: The property to store the pre time stamp.
Post Process: When enabled, generates a time stamp after the step runs.
Property for Post Process: The property to store the post time stamp.
Filter Run Results: Displays the property and values set as a result of running the filter.
Click the Run Filter button to execute the filter and see the results in the Filter Run Results.
Database Filters
These are the filters available in the Database Filters list for any test step.
Extract Value from JDBC Result Set
Simple Result Set Filter
Size of JDBC Result Set
Set Size of a Result Set to a Property
Get Value For Another Value in a ResultSet Row
Extract Value from JDBC Result Set
The filter lets you store the text of a specific JDBC result set value in a property.Extract Value from JDBC Result Set
This filter can be created in two ways; either as a manual filter from the filter list or by using the embedded filter commands on a result set
response.
Creating the filter manually
Enter the following parameters:
Filter in: The name of the property you want considered as the step's last response. The property should be in the pull down menu; if not
you can enter it. It must be an existing property.
Column (1-based or name): The index or name of the column (field).
Row (0-based): The row to retrieve the value. This is a 0-based index.
Property: The name of the property where the value in the cell at the row/column intersection is stored.
Filter Run Results: Displays the property and values set as a result of running the filter.
Click the Run Filter button to execute the filter and see the results in the Filter Run Results.
Creating the filter from a result set response
Display the step response that contains the result set. From within the result set select the cell of the value you want to store in the filter.
Click the Generate Filter icon , shown by the arrow in the previous example.
In the dialog, enter the property key:
Click the OK button.
LISA will create the filter to store the value in the property .sbellum theLogin
Simple Result Set Filter
The filter is used to count the number of rows in a Result Set Response.Simple Result Set
For more information see .Size of JDBC Result Set
Size of JDBC Result Set
(Also known as Simple JDBC Result Set Filter)
The filter lets you check that the result set returned in each JDBC-based step matches the criteria specified. It is aSize of JDBC Result Set
simple filter to handle most common database errors automatically.
This filter does not affect non-JDBC steps, and is usually used as a global filter in a test case.
Enter the following parameters:
Result Set Has Warnings: Some databases return warnings in the result set. If your database supports this feature and you want to
make a warning fire the step for this filter, make sure the check box is selected.On error Result Set Has Warnings
Row Count At Least (>=): The minimum number of rows in the result set. If the result set contains less than this value, the filter sets the
next step to the value specified in step.On Error
Row Count No More Than (<=): The maximum number of rows in the result set. If the result set contains more than this value, the filter
sets the next step to the value specified in step.On Error
On Error: The step to execute if the conditions for this filter are not met.
This filter can serve the purpose of a general global assertion because you can choose a next step based on the presence of an
error.
Set Size of a Result Set to a Property
The filter lets you store the count of a result set to a property provided.Set Size of a Result Set to a Property
Enter the following parameters:
Filter in: The name of the property you want considered as the step's last response. The property should be in the pull-down menu; if not
you can enter it. It must be an existing property.
Property to Store Row Count: User-provided property name to store the row count. The default property name is .PROP
Filter Run Results: Displays the property and values set as a result of running the filter.
Click the Run Filter button to execute the filter and see the results in the Filter Run Results.
Get Value For Another Value in a ResultSet Row
The filter lets you search a column (field) in a result set for a particular value. If the value isGet Value for Another Value in a ResultSet Row
found the value in another column (field) and the same row is placed in a property.
This filter can be created in two ways, either as a manual filter from the filter list, or by using the embedded filter commands on a result set
response.
Creating the filter manually
Enter the following parameters:
Filter in: The name of the property you want considered as the step's last response. The property should be in the pull-down menu; if not
you can enter it. It must be an existing property.
Search Text (Regular Expression): The search string.
Search Column (1-based or Name): The index or name of the column to search.
Value Column (1-based or Name): The index or name of the column to extract the property value.
Property: The name of the property to store the value.
Filter Run Results: Displays the property and values set as a result of running the filter.
Click the Run Filter button to execute the filter and see the results in the Filter Run Results.
Creating the filter from a result set response
Display the step response that contains the result set. From within the result set select the two values in different columns, using the Ctrl key.
Select and then get another column value filter using the Filter icon.Filter for a value
In the dialog that opens, select or reassign the columns for the search and the value, then enter the Property Key:
Click OK.
LISA will create exactly the same filter as the one that was created manually in the previous example.
In the example, will be searched for, and if found, the value in the column of that row will be placed in the property .sbellum EMAIL theEmail
Messaging_ESB Filters
Messaging_ESB Filters
These are the filters available in the Messaging/ESB Filters list for any test step:
Extract Payload and Properties from Messages
Convert a MQ Message to a VSE Request
Convert a JMS Message to a VSE Request
Extract Payload and Properties from Messages
There are several internal properties of messages that LISA will auto extract into properties in the test step using the Extract Payload and
filter. You can also select to auto extract the payload into a property. This is a fast way to get data from a message.Properties from Messages
Different messaging platforms impose various restrictions and can be seen as warnings at execution.
The property names can default to or you can specify the prefix. You can specify an exact name for the payload.lisa.stepName.message
Enter the following parameters:
Filter in: The name of the property you want considered as the step's last response. The property should be in the pull-down menu; if not
you can enter it. It must be an existing property.
Get Payload: Select this if you require payload.
Property key to store the Payload: Enter or select the property key to be used as payload.
Prefix for extracted details: Enter the prefix to be attached to the property name in the result.
Get Message ID: Select to get the Message ID.
Get Correlation ID: Select to get the correlation ID.
Additional Extended Properties: Select to get any additional extended properties.
Run Filter: Click the Run filter button to run and execute the filter. The results can be seen in the Filter Run Results section.
Convert a MQ Message to a VSE Request
The filter is automatically added from the LISA Virtualize recorder. It serves the specific purpose thatConvert a MQ Message to a VSE Request
enables proper functioning with recordings. It should be used carefully and if it is added to a step in a VSE model, it should not usually be
removed or edited.
Filter In: The name of the property you want considered as the step's last response. The property should be in the pull-down menu; if not
you can enter it. It must be an existing property.
Object Form: Select to get the Object Form.
Track Correlation ID: Select to track the correlation ID.
Track Message ID: Select to track the message ID.
Transaction Tracking Type: Select the appropriate tracking type from - Sequential, Correlation ID, Message ID or Message ID to
Correlation ID.
Run Filter: Click the Run Filter button to run and execute the filter. The results can be seen in the Filter Run Results section.
Convert a JMS Message to a VSE Request
The filter is automatically added from the LISA Virtualize recorder. It serves the specific purposeConvert a JMS Message to a VSE Request
that enables proper functioning with recordings. It should be used carefully and if it isadded to a step in a VSE model, it should not usually be
removed or edited.
Filter In: The name of the property you want considered as the step's last response. The property should be in the pull-down menu; if
not, you can enter it. It must be an existing property.
Object Form: Select to get the Object Form.
Track Correlation ID: Select to track the correlation ID.
Track Message ID: Select to track the message ID.
Transaction Tracking Type: Select appropriate tracking type from: Sequential, Correlation ID, Message ID or Message ID to Correlation
ID.
Run Filter: Click the Run Filter button to run and execute the filter. The results can be seen in the Filter Run Results section.
HTTP_HTML Filters
1.
These are the filters available in the HTTP/HTML Filters list for any test step.
Create Resultset from HTML Table Rows
Parse Web Page for Properties Parse HTML_XML Result for Specific Tag_Attributes Values
Parse HTML Result for Specific Tag_Attribute's Value and Parse It
Parse HTML Result for Tag's Child Text
Parse HTML Result for HTTP Header Value
Parse HTML Result for Attribute's Value
Parse HTML Result for LISA Tags
Parse HTML Result and Select Random Attribute Value
Parse HTML into List of Attributes
Parse HTTP Header Cookies
Dynamic Form Filter
Parse HTML Result by Searching Tag_Attribute Values
Create Resultset from HTML Table Rows
The filter lets you create a result set (for example, a JDBC result set) from an HTML table returned inCreate Resultset from HTML Table Rows
the HTML response. The columns and rows of an HTML table can be selected, and LISA will create a result set from them. The result set can
then be used to generate assertions in the same way as it would in a database step.
Although you can create this filter by selecting it from the filter list and filling in the parameters, it is far easier to create it directly from the
HTTP/HTML Request step response using one of the filter commands available to that step. This is the approach we take here. The parameters
produced here, that is, the ones you would have needed to calculate to manually create this filter, are shown later in this section.
To create a filter on a table, record a web page that contains the table, go to the appropriate HTML step, and view it from the DOM tree.
Select the values that are to be placed in the table, using the Cntl key, to select multiple fields. You must select one example value from
each column in the table that you want to use in the result set.
1.
2.
3.
4.
When it is highlighted, select .Create HTML Table Results Filter
Enter the property name in the window.
The property will now be available in the test case.
LISA added this property to the current step. In the following screenshot are the parameters that LISA calculated for this step. These are the
parameters you would have had to supply to manually create this filter.
1.
2.
3.
To show the results of this filter we added a step of type and put in the property created by the filter. TheSave Property as Last Response
result set panel displays the results.
If you are editing an existing test case you may need to replay the test case to generate the property from the filter using the Replay test case to
command. The command is activated using the Replay icon on the toolbar, ora specific point Replay test case to a specific point
from the Command menu. You can now use the embedded filters and assertions that are available at the bottom of the result set window of this
step.
Parse Web Page for Properties
The filter lets you view a rendered web page to create properties from the HTML content. It uses the "paint theParse Web Page for Properties
screen" technique.
"Paint the screen" gives you great flexibility to define what in the HTML you want to parse out as properties. There are three ways to mark the
text:
Text that must appear in the response precisely as shown: a block.Must
Text that is not required to appear in the response, or can change: an block.Any
Text that will be stored in a LISA property: a block.Property
The text is marked using the icons at the bottom of the editor:
This technique is best explained by example. In the following example, see the following example. Assume that we expect that the company
name "ITKO" will change from user to user, and therefore needs to be stored as a LISA property.
We have marked the text using the editor icons, by selecting text and then clicking on the appropriate icon.
Yellow background indicates text that must appear as shown (indicated by the arrows from "Text uses ........." ). This is a block andMust
is marked using the icon.Must
Red background identifies the text that will be stored in the property entered into the dialog ( indicated by a single arrow). This is a
block and is marked using the icon.Property Property
Property blocks must always be bounded by blocks.Must
This screen shows the HTML rendered in a browser in the top panel, and the actual HTML text in the bottom panel. We want to parse out
the website title in the field. We have set the boundaries around that, and clicked the "Must" icon.title
Then we selected the website name text, "LISABank - Home," inside the highlighted content, and clicked the icon . We entered theProperty
property name into the dialog. The website name text has been replaced with the name of the LISA property.
Frequently you can do this purely from the web page view by selecting the content in the web browser. At times, it will be easier to click on the
web browser in the area that you want to select, then make your actual selection in the HTML panel.
Now when this filter is run, the property will be assigned the current value that appears on the HTML page. The website title canWebsiteTitle
change location in the text buffer and it will still be located and parsed for the property.
You can repeat this process on this text buffer to have as many properties defined as you like.
Handling Non-unique Tokens
If you see an error message such as the following:
1.
1.
LISA is telling you that your selected token is not unique; the selection you just made is repeated in the token before it. To solve this in most
cases, simply create another token to make the prior token a token also. In other cases, when this does not work, a judicious placement ofMust
another block in between the two duplicate tokens should work. This will work because LISA can distinguish between the two duplicateMust
tokens based on their relative location.
Parse HTML_XML Result for Specific Tag_Attributes Values
The filter lets you parse the HTML response for a given attribute of a given tag.Parse HTML for Specific Tag/Attribute's Values
This filter can be created in two ways: either as a manual filter from the filter list or by using the embedded filter commands on a result set
response.
Creating the filter manually
Enter the following parameters:
Filter in: The name of the property you want considered as the step's last response. The property should be in the pull-down menu; if
not, you can enter it. It must be an existing property.
Tag: The name of the HTML tag; for an image tag enter .IMG
Tag Count: The occurrence of the tag from the top of response; for the first image tag enter .1
Attribute: The name of the attribute to filter; for the source attribute enter .src
Property: The property in which to store the value.
Default (if not found): The value to use if the attribute value is not found.
URLEncode: When checked, property value is URLEncoded.
Filter Run Results: Displays the property and values set as a result of running the filter.
2. Click the Run Filter button to execute the filter and see the results in the Filter Run Results.
Creating the filter from the HTTP/HTML request step response page
Display the step response that contains the HTML response.
1.
2.
3.
4.
5.
From the DOM Tree view select the attribute whose value you want to store in a property.
When it is highlighted, select .Parse Value Filter
Enter the property name in the window.
Assertions can be also be added here.
Parse HTML Result for Specific Tag_Attribute's Value and Parse It
The filter is really a combination of two other filters: Parse HTML Result for Specific Tag/Attribute's Value and Parse It Parse HTML Result
and .for Attribute's Value Parse Property Value as Argument String
This filter is designed to find a certain attribute in a web page, and then further parse that attribute. If the attribute is a URL, and not just a
name-value pair, there is a function for handling that information.
In this example, we see the filter finds the seventh anchor tag's "href" attribute, which is a URL. The filter takes the "cmd" parameter and stores
that value in the .cmdlist users_KEY
Enter the following parameters:
Filter in: The name of the property you want considered as the step's last response. The property should be in the pull-down menu; if
not, you can enter it. It must be an existing property.
Tag: The name of the HTML tag; for an anchor tag enter .a
Tag Count: The occurrence of the tag from the top of response; for the seventh anchor tag enter .7
Attribute: The name of the attribute to filter; for the href attribute enter .href
IsURL: Select the check box if the attribute value is a URL.
Argument to Parse: The name of the argument to parse for its value; in this example, .cmd
Property: The property in which to store the value; in this example, .cmdlist users_KEY
URLEncode: When checked, property value is URLEncoded.
Default (if not found): The value to use if the attribute value is not found.
Filter Run Results: Displays the property and values set as a result of running the filter.
Click the Run Filter button to execute the filter and see the results in the Filter Run Results.
Parse HTML Result for Tag's Child Text
The filter lets you store the text of a tag's child text in a property.Parse HTML Result for Tag's Child Text
Enter the following parameters:
Filter in: The name of the property you want considered as the step's last response. The property should be in the pull-down menu; if
not, you can enter it. It must be an existing property.
Tag: The type of the tag. For example, for an h1 tag enter .h1
Tag Count: The occurrence of the tag. For the child text of the third h1 tag, enter .3
Property: The name of the property to store the text.
Filter Run Results: Displays the property and values set as a result of running the filter.
Click the Run Filter button to execute the filter and see the results in the Filter Run Results.
Parse HTML Result for HTTP Header Value
The filter lets you store the value of a returned HTTP header key in a property.Parse HTML Result for HTTP Header Value
A common use of this filter is saving the HTTP header in a property named SERVER_NAME.Server
Enter the following parameters:
Filter in: The name of the property you want considered as the step's last response. The property should be in the pull-down menu; if
not, you can enter it. It must be an existing property.
HTTP Header Key: The name of the HTTP header; for example, Server.
Property: The property to store the header value.
Filter Run Results: Displays the property and values set as a result of running the filter.
Click the Run Filter button to execute the filter and see the results in the Filter Run Results.
Parse HTML Result for Attribute's Value
The filter lets you store the text of a specific attribute in a property. The attribute can occur anywhereParse HTML Result for Attribute's Value
in the result, including scripting code.
The parameters set are:
Filter in: The name of the property you want considered as the step's last response. The property should be in the pull-down menu; if
not, you can enter it. It must be an existing property.
Attribute: The type of attribute to retrieve. For example, if you want the URL of an anchor tag, enter .href
Count: The occurrence of the tag. For example, if you want the URL of the third anchor tag on the page, enter .3
Property: The property to store the text of the attribute; in this example, .anchor3
Filter Run Results: Displays the property and values set as a result of running the filter.
Click the Run Filter button to execute the filter and see the results in the Filter Run Results.
Parse HTML Result for LISA Tags
The filter provides a way for developers to test-enable their web applications. For an in-depth study onParse HTML Result for LISA Tags
test-enabling, see the . Developer's Guide (SDK)
This filter provides the ability to insert "LISAPROP" tags into your web page. The LISAPROP tag has two attributes: name and value. The
LISAPROP tags do not show up in your web pages. They function only to discretely provide valuable information about your web page to a tester.
An example of a LISAPROP might be:
<LISAPROP name="FIRST_USER" value="sbellum">.
If a tester has installed this type of filter, the property will automatically be assigned the value . This removes any need forFIRST_USER sbellum
the tester to parse for this value. This type of filter helps a developer make the testing easier.
Frequently a web page will not contain the information needed to perform proper validation, or that information is very difficult to parse. Even
when it is there, the parsing can become incorrect because of subtle changes in the HTML that is generated. This LISAPROP filter can resolve
many tedious parsing issues for web testing.
There are no parameters required.
Parse HTML Result and Select Random Attribute Value
The filter lets you store the text of a random selection from a set in a property. TheParse HTML Result and Select Random Attribute Value
attribute can occur anywhere in the result, including scripting code.
Enter the following parameters:
Filter in: The name of the property you want considered as the step's last response. The property should be in the pull-down menu; if
not, you can enter it. It must be an existing property.
Outer Tag: The outer element that contains the list from which to pick. For example, to select a drop-down menu, you would enter the
text .select
Tag Count: The occurrence of the outer tag. For example, to select the second drop-down menu, you would enter the text "2".
Inner Tag: The tag to randomly pick the attribute from. To pick a random item in the drop-down menu, you would enter the text .option
Filter Attribute: Optional field to specify attribute names that should not appear in the pick list.
Filter Value: Optional field to specify attribute values that should not appear in the pick list.
Attribute: The attribute from which to retrieve text. If this is blank, the child text of the inner tag is returned.
Property Key: The property to store the text of the attribute.
Filter Run Results: Displays the property and values set as a result of running the filter.
Click the Run Filter button to execute the filter and see the results in the Filter Run Results.
Parse HTML into List of Attributes
The filter lets you store the text of a set of attributes, as a list, in a property.Parse HTML into List of Attributes
Filter in: The name of the property you want considered as the step's last response. The property should be in the pull-down menu. If
not, you can enter it. It must be an existing property.
Outer Tag: The outer element that contains the list of tags to parse. For example, to store all the links from all the anchor tags in a table,
enter .table
Outer Tag Count: The occurrence of the outer tag. For the second table, enter .2
Inner Tag: The tag to retrieve the values from. For example, for all the anchor tags in the table enter .a
Filter Attribute: Optional field to specify attribute names that should not appear in the pick list.
Filter Value: Optional field to specify attribute values that should not appear in the pick list.
Attribute: The attribute of the Inner Tag to retrieve the text from. If this is blank, the child text of the Inner Tag is returned. To store all the
links from all of the anchor tags in a table, enter .href
Property Key: The name of the property to store the text of the attribute.
Filter Run Results: Displays the property and values set as a result of running the filter.
Click the Run Filter button to execute the filter and see the results in the Filter Run Results.
Parse HTTP Header Cookies
The filter lets you parse the HTTP header for cookie values, and store them in a property starting with a specificParse HTTP Header Cookies
prefix.
Enter the following parameters:
Filter in: The name of the property you want considered as the step's last response. The property should be in the pull-down menu; if
not, you can enter it. It must be an existing property.
Property Prefix: A text string that will be prefixed to the cookie name to provide the property name to use. The full names of these
properties are therefore dependent on the names of the cookies that have been returned. The cookie names can be identified in the
property tab of the Interactive Test Run (ITR).
Filter Run Results: Displays the property and values set as a result of running the filter.
Click the Run Filter button to execute the filter and see the results in the Filter Run Results.
Dynamic Form Filter
The filter identifies dynamically generated forms in HTML responses and parses them into a set of properties. The property keyDynamic Form
that you enter becomes part of the property name for each form element in each form. This is easier to understand by examining the example that
follows.
You might test an HTML page with two dynamically generated forms:
<form name="F001" action="index.jsp"> <input type="text" name="0001A" value="default" /> <input
type="text" name="0001B" value="" /></form>
<form name="F002" action="orders.jsp"> <input type="text" name="0002A" value=Key"" /> <input
type="text" name="0002B" value="" /></form>
Using a property key of in the filter panel would create the following key-value pairs:FormTest
Key Value
FormTest.Form1.text1.name 0001A
FormTest.Form1.text1.value default
FormTest.Form1.text2.name 0001B
FormTest.Form1.text2.value
FormTest.Form2.text1.name 0002A
FormTest.Form2.text1.value
FormTest.Form2.text2.name 0002B
FormTest.Form2.text2.value
Parse HTML Result by Searching Tag_Attribute Values
The filter lets you filter the value of a tag attribute by searching for the name and valueParse HTML Result by Searching Tag/Attribute Values
of another attribute in that tag. If more than one tag fits the criteria you can specify which one you want.
The parameters set are:
Filter in: The name of the property you want considered as the step's last response. The property should be in the pull-down menu; if
not, you can enter it. It must be an existing property.
Tag: The name of the tag to search.
Search Criteria Attribute: The attribute to search for.
Search Criteria Value Expression: The attribute expression to search for.
Tag Count: The specific tag to use from those that satisfy the search criteria.
Attribute: The attribute whose value you want.
Property: The property in which to store the value.
Default (if not found): The value to use if search is not successful.
URLEncode: When selected, the value is URLEncoded.
Filter Run Results: Displays the property and values set as a result of running the filter.
Click the Run Filter button to execute the filter and see the results in the Filter Run Results.
XML Filters
These are the filters available in the XML Filters list for any test step:
Parse text from XML
Read Attribute from XML Tag
Parse XML Result for LISA Tag
Choose Random XML Attribute
XML XPath Filter
Parse text from XML
1.
1.
2.
3.
(Also known as Parse XML Result for Tag's First Child Text)
The filter stores the text of a tag's child text in a property. To define a filter, set the type of the filterParse text from XML Parse text from XML
and set the three attributes.
This filter can be created in two ways: as a manual filter from the filter list or by using the embedded filter commands on an XML response.
Creating the filter manually
Enter the following parameters:
Filter in: Where to apply the filter. This illustration shows , which means that the filter will be applied tolisa.Add User Object XML.rsp
the response of . You can edit this value for this filter.Add User Object XML
Tag: The type of the tag. For example, if you want the child text of the multiRef tag, enter .multiRef
Tag Count: The occurrence of the tag. For example, if you want the child text of the first multiRef tag, set the Count to .1
Property: The name of the property to store the text.
Filter Run Results: Displays the property and values set as a result of running the filter.
2. Click the Run Filter button to execute the filter and see the results in the Filter Run Results.
Creating the filter directly from the response page
From the DOM Tree view select the attribute whose value you want to store in a property.
After it is selected, select Generate Filter for Attribute or Text.
Enter the property name in the dialog window.
3.
1.
Assertions can also be added here.
Read Attribute from XML Tag
(Also known as Parse XML for specific Tag/Attribute's Value)
The filter lets you store the text of a specific attribute in a property. The attribute can occur anywhere in the result.Read Attribute from XML Tag
This filter can be created in two ways: either as a manual filter from the filter list, or by using the embedded filter commands on an XML response.
Creating the filter manually
Enter the following parameters:
Filter in: Where to apply the filter. The previous illustration shows , which means that the filter will belisa.Add User Object XML.rsp
applied to the response of the Add User Object step.
Tag: The name of the XML tag; for example, .target
Tag Count: The occurrence of the tag from the top of response; for the first tag enter .1
Attribute: The name of the attribute to filter; for the href attribute enter .href
Property: The property in which to store the value.
Default: The value to use if the attribute value is not found.
URLEncode: When checked, property value is URLEncoded.
Filter Run Results: Displays the property and values set as a result of running the filter.
Click the Run Filter button to execute the filter and see the results in the Filter Run Results.
Creating the filter from the response page
Display the step response that contains the XML.
1.
2.
3.
4.
From the DOM Tree view, select the attribute whose value you want to store in a property.
When it is highlighted, select .Generate Filter for Attribute or Text
Enter the property name in the window.
You can also add an assertion at this point if you want. A Property Value Expression Assertion can be added to this step.
Parse XML Result for LISA Tag
The filter provides a way for developers to test-enable their XML applications. For an in-depth study onParse XML Result for LISA Tags
test-enabling, see the . Developer's Guide (SDK)
This filter provides the ability to insert LISAPROP tags into your XML page. The LISAPROP tag has two attributes: name and value. The
LISAPROP tags function only to discretely provide valuable information about your XML to a tester. An example of a LISAPROP might be:
<LISAPROP name="FIRST_USER" value="sbellum">.
If a tester has installed this type of filter, the property "FIRST_USER" will automatically be assigned the value "sbellum". This removes any need
on behalf of the tester to parse for this value. This type of filter helps a developer make the testing easier.
The XML may not contain the information needed to perform proper validation, or that information is very difficult to parse. Even when it is there,
the parsing can become incorrect due to subtle changes in the XML that is generated. This LISAPROP filter can resolve many tedious parsing
issues.
There are no parameters required.
Choose Random XML Attribute
The filter lets you store the text of a random selection from a set in a property. The attribute can occur anywhereChoose Random XML Attribute
in the result. This filter works exactly like .Parse HTML Result and Select Random Attribute Value
XML XPath Filter
The filter lets you use an XPath query that will be run on a property, or the last response and store it in a property. When this filter isXML XPath
selected, the last response is loaded into the content panel.
The response can be viewed as an XML document or as a DOM tree. However, the XPath selection can be made only from the DOM tree.
Construct the XPath query by using one of the following methods:
Manually enter the XPath expression in the XPath Query text box.
Select an element from the DOM tree and let LISA construct the XPath expression.
Select an element from the DOM tree, and then edit the XPath that is constructed. For example, you may want to modify it to use a LISA
property, or a counter data set.
Enter the following parameters:
Filter In: Enter the last response or a named property.
Save To Property: The property in which to store the result of the XPath query.
Now construct the XPath query using one of the methods described earlier.
After an XPath query has been constructed, test it by clicking Run Filter. The results of the query appear in the pane.Filter Run Results
The property controls whether the XPath function is always used duringlisa.xml.xpath.computeXPath.alwaysUseLocalName local-name()
XPath generation. The default value is , which means that the function is used only when necessary. To generate an XPathfalse local-name()
that will work regardless of an XML node's namespace, set the value to .true
Web 2.0 Filters
These are the filters available in the Web 2.0 Filters list for any test step:
Web 2.0 Element Filter
Web 2.0 Text Filter
Web 2.0 Attribute Filter
Web 2.0 JavaScript Filter
Web 2.0 Function Filter
Web 2.0 Composite Filter
Web 2.0 Element Filter
The lets you retrieve an HTML element from the response and store it in a property.Web 2.0 Element Filter
Enter the following parameters:
HTML Element XPath: The XPath expression that uniquely identifies the DOM element that was the target of the event.
Function: Name of predefined Web 2.0 function.
Property: The name of the property to store the result.
Web 2.0 Text Filter
The lets you retrieve text from the response using an XPath expression and then a regular expression, and then store theWeb 2.0 Text Filter
text in a property.
Enter the following parameters:
HTML Element XPath: The XPath expression that uniquely identifies the DOM element that was the target of the event.
Regular Expression: A regular expression that is applied to the result of the filter to further control what gets returned.
Function: The name of a predefined Web 2.0 function.
Property: The name of the property to store the result.
Web 2.0 Attribute Filter
The lets you retrieve an HTML attribute value from the response and store it in a property.Web 2.0 Attribute Filter
Enter the following parameters:
HTML Element XPath: The XPath expression that uniquely identifies the DOM element that was the target of the event.
Attribute Name:The optional DOM attribute name used to execute DOM attribute filters.
Function: The name of a predefined Web 2.0 function.
Property: The name of the property to store the last response.
Web 2.0 JavaScript Filter
The lets you retrieve arbitrary information from the response using a JavaScript expression.Web 2.0 JavaScript Filter
Enter the following parameters:
HTML Element XPath: The XPath expression that uniquely identifies the DOM element that was the target of the event.
Javascript Function: A snippet of valid JavaScript code that gets executed by the filter. It should return an object.
Function: The name of a predefined Web 2.0 function.
Property: The name of the property to store the result.
Web 2.0 Function Filter
The lets you execute a predefined Web 2.0 function.Web 2.0 Function Filter
Enter the following parameters:
HTML Element XPath: The XPath expression that uniquely identifies the DOM element that was the target of the event.
Function: The name of predefined Web 2.0 function.
Property: The name of the property to store the last response.
Web 2.0 Composite Filter
The lets you combine other Web 2.0 filters using a string or an arithmetic expression.Web 2.0 Composite Filter
Enter the following parameters:
Composite Expression: Expression with Web 2.0 filters using a string or arithmetic expression.
Function: Name of a predefined Web 2.0 function.
Property: The name of the property to store the result.
Java Filters
These are the filters available in the Java Filters list for any test step.
Override "Last Response" Property
Save Property Value to File
Store Step Response
Java Override "Last Response" Property Filter
There is a special property known as Last Response, which contains the response from the previous step. For example, if the previous response
was an HTTP step, the last response will be a web page that was returned.
The filter should be used if you want the last response to be something other than the default value. ThisOverride "Last Response" Property
filter lets you replace the current value of the last response with the value of an existing LISA property.
Click the filter to open its editor.
Enter the following parameters:
Filter in: The name of the property you want considered as the step's last response. The property should be in the pull-down menu; if
not, you can enter it. It must be an existing property.
Convert to XML: Check this if you want the response to be converted to valid XML.
Filter Run Results: Displays the property and values set as a result of running the filter.
Click the Run Filter button to execute the filter and see the results in the Filter Run Results section.
For more detailed information see Utility Filters: .Override Last Response Property
Java Save Property Value to File Filter
The filter lets you save the value of an existing property to a file in your file system.Save Property Value to File
Enter the following parameters:
Filter in: The name of the property whose value you want to write to the file.
Location: The path name of the file to write the value to. You can browse to the file. You can use properties in the location.
Append Mode: Select this check box if you want to append the information to an existing file.
Filter Run Results: Displays the property and values set as a result of running the filter.
Click the Run Filter button to execute the filter and see the results in the Filter Run Results.
Java Store Step Response Filter
(Also known as Save Step Response as Property Filter)
The filter lets you save the last response as a property, for future use.Store Step Response as Property
Enter the following parameter:
Filter in: Enter the response to apply the filter to. The previous illustration shows , which means that the filter will belisa.Add User.rsp
applied to the response of . You cannot change this value for this filter.Add User
Property: The name of the property to store the last response.
Filter Run Results: Displays the property and values set as a result of running the filter.
Click the Run Filter button to execute the filter and see the results in the Filter Run Results.
VSE Filters
This is the filter available in the VSE Filters list for any test step.
Data Protocol Filter
1.
2.
Data Protocol Filter
The filter is used on protocol-specific listen steps for virtual models. It provides the necessary wrapper for a data protocol to act asData Protocol
a filter, the appropriate way for things to work in the run-time side of VSE.
Click the filter to open its editor.
Enter the following parameters:
Filter in: Enter the response to apply the filter to. The previous illustration shows , which means that the filter will belisa.Get User.rsp
applied to the response of . You cannot change this value for this filter.Get User
Data Protocol: Select the appropriate data protocol to be used from the drop-down list.
Process Requests: Check to see the process request.
Process Responses: Check to see the process response.
3. Click the Run Filter button to execute the filter and see the results in the Filter Run Results section.
Pathfinder Filters
These are the filters available in the Pathfinder Filters list for any test step.
LISA Integration Support for Pathfinder
LISA Integration Support for webMethods Integration Server
LISA Integration Support for Pathfinder
The filter is a common filter to enable Pathfinder for all the technologies supported by LISA. This filterLISA Integration Support for Pathfinder
collects additional information from a Pathfinder application.
Currently LISA supports integration with web services, JMS, servlets, EJB and Java objects.
Enter the following parameters:
Error if Max Build Time (millis) Exceeds: Enter build time in milliseconds. If it exceeds the time specified, an error will be generated.
On Transaction Error Step: Select the step to redirect to on transaction error after filter is set to run.
On Pathfinder Warning Step: Select the step to redirect to on Pathfinder Warning Step after filter is set to run.
Report Component Content check box: Generate a report of the component content.
Force a Garbage Collection on the server at the start & end of the request check box: Forces a garbage collection on the server at
the start and end of the request.
Fail test if server-side exception is logged check box: Fail the test case if exception is thrown at the server side.
Log4J level to capture in the test events: Select the log4J level that is to be captured in the test events.
Log4J Logger to temporarily change (blank is Root Logger): Enter the name of the logger.
LISA Integration Support for webMethods Integration Server
The filter collects additional information from Pathfinder-enabled webMethodsLISA Integration Support for webMethods Integration Server
Integration Server.
Enter the following parameters:
Error if Max Build Time(millis) Exceeds: Enter build time in milliseconds. If it exceeds the time specified, an error will be generated.
On Transaction Error Step: Select the step to redirect to on transaction error after filter is set to run.
On Pathfinder Warning Step: Select the step to redirect to on Pathfinder Warning Step after filter is set to run.
Assertions
An assertion is a LISA code element that runs after a step and all its filters have run, to verify that the results from running the step match
expectations.
The result of an assertion is a Boolean value (true or false).
The outcome may determine whether the test step passes or fails, and also determines the next step to run in the test case. An assertion is used
to dynamically alter the test case workflow by introducing conditional logic (branching) into the workflow – very much like an 'if' conditional block
programming.
For example, you might create an assertion for a JDBC step that helps ensure that only one row in the result set contains a specific user name. If
the results of the JDBC step contain more than one row, the assertion changes the next step to execute. In this way, an assertion provides
conditional functionality.
The test case flow is usually modeled with one of the following two possibilities:
The next step defined for each step is the next logical step in the test case – in which case the assertions are pointing to failure; or
The next step is set to fail, and the assertions all point to the next logical step.
The choice will depend, for the most part, on the actual logic being employed.
If an assertion references an unresolved property, a model definition error will be raised. The model definition error will not
cause the test to terminate, but it will caution the test author that an unresolved property was encountered. The problem created
by an unresolved property is that an assertion cannot give the proper verdict because the assertion does not have enough
information to do so, resulting in false positives or false negatives. (Most assertions return "false" as the verdict if an unresolved
property is encountered, but that is not an enforced rule.) By running a test in the ITR and inspecting the test events panel for
model definition errors, a test author can determine if any unresolved properties exist.
You can add as many assertions as you need, giving you the capability to build a workflow of any complexity that you need. Nothing except
.assertions can change the LISA workflow
Assertions are executed in the order that they appear, and the workflow logic will usually depend on the order that the
assertions are applied.
After an assertion fires, the next step can be configured and is determined by that assertion, and the remaining assertions are ignored. An event
is generated every time an assertion is evaluated and fired.
Global and Step Assertions
Like filters, assertions can be applied as a global assertion, that is, to the entire test case cycle or as a step assertion, where they will be applied
only to a particular step.
The following topics are available in this chapter.
Adding an Assertion
Assertions Toolbar
Deleting an Assertion
Reordering an Assertion
Renaming an Assertion
Dragging and Dropping an Assertion
Configuring the Next Step of an Assertion
Types of Assertions
Adding an Assertion
There are several ways to add assertions into the test case.
Adding an Assertion Manually
Adding an Assertion from an HTTP Response
Adding an Assertion from a JDBC Result Set
Adding an Assertion for Returned Java Object
All methods except the first imply using assertions that are available for selection in the specific test step editor.
Adding an Assertion Manually
To add an assertion manually
Select the assertion type from a list and enter the parameters for the assertion.
There are two types of manual assertions:
Global assertions are defined at the test case level. This type of assertion will be applicable to all the steps in the test case and is
automatically run for every step in the test case, unless a given node is instructed otherwise.
Step assertions are defined at the test step level. This type of assertion will be applicable only to that step and will execute for that step
only.
Adding a Global Assertion
To add a global assertion
Open a test case and in the right panel click the element.Global Assertions
You can apply the following types of global assertions:
HTTP
Simple Web Assertion
Check Links on Web Responses
XML
Ensure Step Response Time
Other
Ensure Result Contains Expression
Ensure Step Response Time
Scan a File for Content
The following image shows a global assertion applied to the test case.multi-tier-combo
Adding a Step Assertion
To add a step assertion
Select the step for which you want to apply the assertion and in the right panel click the element, or right-click the step and select Assertion Add
and select the appropriate assertion for the step.Assertion
The following image shows step assertions applied to the step in the test case.Add user multi-tier-combo
To add an assertion, click the icon on the assertion toolbar.Add
Or, you can right-click a step in the model editor to add an assertion. The assertion panel opens up and shows a menu of assertions that can be
applied to the step.
1.
2.
3.
4.
Selecting/Editing an Assertion
Click the step in the model editor to which the assertion is applied and/or click the assertion related to that step in the Assertion tab.
Double-click the assertion to open the assertion editor. The editor is unique for each type of assertion.
Adding an Assertion from an HTTP Response
When you have access to the response from an HTTP-based step, you can use the response to add an assertion directly.
This example of the HTTP/HTML response uses the login step in the multi-tier-combo test case. The point of this example is to test whether the
text "MyMoney Home" appears in the response.
Run the multi-tier-combo test case in the ITR.
Double-click the login step in the model editor.
Select the text "MyMoney Home" in the View tab.
Click the DOM Tree tab to view and make sure that this text is selected in the tree.
4.
5.
6.
From the Select a Command pull-down menu at the bottom of the panel, select Make Assert on Selection.
In the window that is displayed, enter the expression that the selected text should match with, and select the appropriate assertion
behavior.
6.
7.
8. In this example, the assertion fires if the text "MyMoney Home" is not present, and then redirects to the fail step.
Click OK to save the assertion.
The assertion that was generated can be seen as an assertion in the login step.
Running one Filter and one Assertion
Alternatively, if you wanted a filter to capture the value "MyMoney Home," and then run it as an assertion, you can use the ,Parse Value Filter
which can do both things.
The window displayed by the Parse Value Filter shows Property Key value is the filter to be applied and Expression is the assertion to be fired.
As a result, one filter and one assertion will be added to the login step and can be seen in the model editor.
The same assertion capabilities are available when an HTML response is displayed in the step editor.
Adding an Assertion from a JDBC Result Set
1.
2.
3.
When you have access to the Result Set response from a JDBC step, you can use the response to add an assertion directly. The following is an
example of how to add an assertion this way.
Here is an example for a result set response, using the response of Verify User Added step in multi-tier-combo test case in the examples
directory (multi-tier-combo.tst).
Select the Verify User Added step, and double-click it to open its editor window. Edit the SQL statement to read .select * from users
Click the Test/Execute SQL button to run the query.
Select the Result Set tab and click the cell in the result set that represents the information that you want to test for (for example, sbellum
).
3.
4.
5.
Click the Generate Assertions for Cell's Value icon in the toolbar below the Result set window.
We want to test that appears in a cell in the column.sbellum LOGIN
In the dialog that opens, enter the test step (fail) to redirect if the value is not found:
LISA will create an assertion named Result Set Contents in the Verify User Added step.
The same assertion capabilities are available when a JDBC result set is displayed in the step editor.
Adding an Assertion for Returned Java Object
When the result of your test step is a Java object, you can use the inline assertion panel in the Complex Object Editor to add an assertion on the
returned value from the method call directly. The following is an example of how to add an assertion this way.
Here is an example of an object in the Complex Object Editor:
This example uses the get user (an EJB step) step in multi-tier-combo test case in the examples directory (multi-tier-combo.tst).
We have entered an input parameter , and executed the method call getUser. We are now about to execute the getPwd call on the UserStateitko
object that was returned from that call.
1. Select the Expert Mode check box in the left pane, to open the Status/Result pane where you can add the assertion.
1.
2.
3.
4.
The returned value upon executing the getPwd method will be stored in the property CurrentPassword.
Add an assertion that tests to see if the returned value is equal to the string "test". If it is not that, then redirect to the Fail step.
Click Execute to execute this step.
In-line assertions (and filters) do not result in an assertion being added to the test step. In-line assertion management is always
done in the Complex Object Editor.
For old test cases, all inline assertions that were set to the Fail step, will now change to the Abort step.
For more details on the Complex Object Editor, see .Complex Object Editor (COE)
Assertions Toolbar
All the elements have their own toolbar to add/delete/reorder at the bottom of the element.
1.
2.
3.
1.
Deleting an Assertion
To delete an assertion
Right-click any assertion in the Elements tab to open a menu. Click Delete to delete the assertion.
Select the assertion in the test step and right-click to open a menu. Click Delete to delete the assertion.
Select the assertion in the Elements tab and click the Delete icon on the toolbar.
Reordering an Assertion
You may need to reorder assertions, because assertions are evaluated in the order in which they appear. Thus, changing the order of the
assertions can affect the workflow.
To reorder an assertion
Select the assertion in the Elements tab and click the Move Up or Move Down icon on the toolbar.
Drag and drop the assertion in the model editor to the target destination.
Renaming an Assertion
To rename an assertion
Select the assertion and right-click to open a menu. Click Rename to rename the assertion.
Select the assertion and click the Rename icon on the toolbar.
Dragging and Dropping an Assertion
You can drag and drop assertions in the model editor from one test step to another.
Click the assertion in one test step; for example, .Step1
Select and drag the assertion to other test step in the model editor; for example, .Step2
The dragged assertion will then be applied to .Step2
Configuring the Next Step of an Assertion
An assertion added to a step can be seen in the model editor.
After the assertion is added to a step, you can select its next step to be executed, if you want the workflow to be altered.
Right-click the assertion in the Model Editor to open the menu.
1.
2. Select and do one of the following:If triggered, then
Select to generate a warning or error.
Select to end, fail, or abort the step.
Select the next step to be executed.
Types of Assertions
This section describes each of the assertions that are available in LISA.
Regular expressions are used for comparison purposes in many assertions. For more information about regular expressions, visit
.http://download.oracle.com/javase/tutorial/essential/regex/
HTTP Assertions
Database Assertions
Web 2.0 Assertions
XML Assertions
Virtual Service Environment Assertion
Other Assertions
HTTP Assertions
The following assertions are available in the HTTP assertions list for any test step:
Highlight HTML Content for Comparison
Check HTML for Properties in Page
Ensure HTTP Header Contains Expression
Check HTTP Response Code
Simple Web Assertion
Check Links on Web Responses
Highlight HTML Content for Comparison
The assertion lets you make a comparison based on the contents on an HTML page. This assertionHighlight HTML Content for Comparison
uses the "paint the screen" technique specifically designed to work with HTML pages. For example, if there is a large HTML document, then you
can identify the data before and after the "content of interest". Then you simply identify what the "content of interest" will be compared against
(usually this would be an expected value supplied in a data set).
The text is marked using the icons at the bottom of the editor: