introduction v4

Sanjay Rukmangada269-873-4631

Agenda

• Notes about this presentation• Intro to LISA• Components in LISA architecture• How it is deployed• Core Concepts of LISA• UI Navigation within LISA• Next Steps• Resources

Notes about Presentation

• Lots of information• Lots of spoken information• Even though short – ask your questions

– Better served by rating quality over quantity• Architecture is very important – because it changes the way we do things• Take notes as appropriate – will save you time• Augment this presentation by watching demo videos• DO ask the question “We want to do ‘y’, how does LISA do it?”• This presentation will NOT include information about Virtualization

Intro to LISA

• Lisa is an integrated SOA testing tool• It tests L&P, UI, Web Services, EJB, JUnit, etc.• iTKO – Interactive Technical knockout• 4 Parts to LISA – Bought together or separate:

LISA Test LISA Virtualize LISA Validate LISA Pathfinder

• Everything controlled by licenses –just one product• The LISA tool is file based.

Components in LISA Architecture

• Test Manager UI: Is the program on your desktop that you will be working in most of the time • Coordinator: Tells components what to do (test), collects metrics, writes results• Simulator: Actually runs the test (1 to many users – L&P uses more. QA will only use 1)• Registry: Sole job is to keep track of everything.

• Local Mode: everything is on your machine

• Server Mode: Only Test Manager is on your machine. Other 3 components are on a shared box.

How LISA is deployed

Base ServerBase Server

Virtual ServerVirtual Server

Workstation(Desktop)

Workstation(Desktop)

Workstation(Desktop)…………….

Coordinator Server

Simulator Server

Registry Server

ResultsDatabase

Core Concepts of LISA


• Projects: The folder structure signifies the entire project.

• It is divided into folders that represent the various artifacts (testcases, suites, data files, virtual services, etc.)

• Represented by a single project file in the file system – but accompanied with a folder structure.

• Only one project open at a time.


• Test Step: Essentially are the ‘Do What’ of test cases• Each test case can have multiple test steps• Examples: Raw SOAP, jdbc, MQ, etc.• Simply right click on the canvas and pick your step!• Symbols help differentiate between various steps


• On the Right are the various features of a test step.

• Most are common for every test step. Important ones are Filters, Assertions, Log Message, Data Sets, Documentation

• The step information contains three key pieces of information:• Name: Name of the step• Think time: Time to wait, range to wait, a Delay

• Next: What step to execute next. Key to forming workflows.

• After looking at the work flow since everything is a block – every block/step has a ‘RESPONSE’


The core of each step is context sensitive. The screens that pop out from the right change per the step.

To the right are examples of a JDBC step (above) and a WSDL Step

The best way to understand a step is to: – Go through the official

LISA Documentation– Open it and look at the

options. – There will an additional

document that goes over key steps and particular step details.


• Filter: “gets what you want to look at”• Since every test step has a response, we can feed that response into a filter.

• The filter can parse data from XML, text files, SQL results, create dates, etc.

• There are a myriad of filters for various purposes• Filters do not VALIDATE anything. They SELECT things.• Example:

• Web Service Step does NOT DO anything besides send request and get response.

• The Filter actually goes into the response and then gets us back • individual elements to “send to cache” or gets us the • entire step response


• Assertion: Actually “VALIDATE”• Many kinds of assertions, but not as many as the kinds of filters

• Golden Copy will typically how we use it: referred to as a Graphical XML Side-by-Side Comparison (Graphical XML Diff)

• Summary: The step feeds into a filter, which feeds into an assertion. • Note: If you are feeding the entire response of the test step into an assertion, you can bypass the filter. Eg. in a web service step, you want to validate the entire response, so we would feed the response of the Web Service step into the Graphical XML Diff.


• Data Set: Simply a mechanism to read data not contained in individual test steps.

• The workflow diagram is above• The various features of the data set are on the right• Important step is the “At end” option. Choice to go

to next step or restart (picked only if another terminator is present).

• Suggestion for Customer Data: All Customer/Account data lives in files

• Pro: Tests can be shared with development or other QA groups and even Dev groups


• LISA Property: similar to the cache variables in Integra.• Essentially they are variables within LISA.• To reference a LISA property you simply include the variable name within

curly braces eg. {{name}}.• The curly braces essentially mean: ‘value of’• We can initialize PROPERTIES by:

{{num=3}} or {{name=“bob”}}• We can also specify properties in a file in either key=value format or xml

format and use a particular filter to read them in.• Very importantly, filters can be used to ‘slice and dice’ a TEST STEP’S

response to then push a portion (or element) of the response into a PROPERTY.


• Config Files: These files store various LISA properties. • Typically used to indicate environment specific information.• Eg. in OPS we would use QA1.config, QA2.config, QA6.cofig.• Only 1 config file can be active at once.• Typically every property in one config file will exist in every other• In QA: all messages (projects) for the same service will have the same properties.


• Test Suites: collection of tests• Add tests in many ways• Run against a staging

document• Pick the coordinator server by

default you want this run on• In our case, probably Base

Server• In the lower portion:• Add tests, directories, other

suites, directory trees• Serial Vs. Parallel – TBD

• Only regression suites will be LISA suites – not individual TCs• OFFICIAL suite runs should be done when Registry points to base server – This has to do with RESULTS STORAGE


• Staging Document: Gives details about how a test is to be run

• Keep in mind that some/many options hail from a L&P POV• Instances• Cycles • MAX Run Time• Distribution Selection• Simulator Spread

• Reports – will be saved in Results DB• Metrics – typically for L&P, but

possibly useful for Web SVC testing


• Reports: How you will be looking at test runs for historical purposes

• You need to have Adobe Flash plug-in on your system• Still in the nascent stages of usage• The best way to go through this is with a demo, but we will not since we have open questions with iTKO

UI Navigation within LISA

Resources

• www.itko.com• Official LISA Documentation and User Guide• Videos that show multiple smaller steps/scenarios• Web SVC QA’s iTKO LISA Best Practices Documents• [email protected] • Measure twice and cut once Measure twice and cut once – if you are not sure about what to do, please ask. It is twice as expensive to fix a mistake once someone else finds it.

http://www.itko.com/

mailto:[email protected]

Questions

introduction v4

Education

Transcript of introduction v4