automated tests

Hi all,

We are trying to run set up some automated tests with Teamsite so simulate the user input on dct as well as on Content Center professional to trigger off workflows and then to evaluate the impact on the website. We need to idetify the exact location and name/id of each control and item in the dct as well as on Content Center professional. I was wondering if anyone has done this before and what the problems where.

We've got a test running and is is supposed to do the following tasks:
-In Content Center professional click "File" from the main menu. The location of control is "menu0_popup_trigger_li" (This is working and the Drop down menu is showing "New File", "New Form Entry", etc.
-Next Task is to click "New Form Entry" from this drop down menu. The location of this control is "iw.ccpro.file_menu.create_form.link" But then the problems start since we get an error saying that the vpath (of the left frame) missing when clicking "New Form Entry".
-More Taks to come
-Finally we want to add values to the items in our dct's but we again fail to identify the exact location of the items (textarea or text) since most of the dct window is made up of JavaScript.

Any ideas will be highly appreciated

Environment TS: iwserver: 6.1.0 Build 36267 Interwoven 20040610 on Solaris

Find more posts tagged with

Comments

Lozza

I've made some good progress with automated testing of TeamSite. I used a tool called Selenium, which drives the browser as the end user would. Selenium needs to be installed on the TeamSite server, as JavaScript security requires scripts to be on the same domain as the documents they're trying to manipulate. Selenium can be installed in its own folder under iw-home/httpd/webapps/content_center

Selenium tests are constructed in HTML table format, with one row per step, and three columns per row. The first column contains a command to execute, e.g. click, open, verifyTextPresent, selectWindow etc. The second and third columns are the arguments for that command. Most need just one (e.g. click link=OK) whereas others need two (e.g. type passwordbox myp4ssw0rd).

I have a few tips regarding driving the TeamSite interface generally:

Use a developer toolbar (e.g. Microsoft's recent Beta Developer Toolbar for IE, which is very good) to capture the IDs of any page elements. This toolkit lets you select a page element and learn its ID, and navigate around picking out interesting things like values, classes, alt values etc.
I found it near impossible to drive the menus and interface, and had to navigate direct to internal TeamSite URLs. If you want to test editing a DCR, for example, navigate direct to /iw-cc/command/iw.ccpro.launch_edit_form?vpath=//server/default/main/etc/pathtodcr&redirect=false instead of trying to toy with the dynamic drop-down menus (e.g. File > New Form Entry etc)
Remember that any automated tests are very likely to require a rewrite when you upgrade to a newer version of TeamSite.

Some page elements are difficult to address, because they don't have an ID, because they're nested deep within a frameset, or for various other Annoying Unknown Reasons. An example of a page where I had a problem is the TeamSite login page, scripting the login of a test user. For some reason, typing into elements with an ID iw_password and iw_user didn't work. However it did work if I addressed them using the JavaScript DOM. Here follows some example Selenium commands, which I used at the beginning of each of my tests:

open	http://app-dev003.hld.uk.fid-intl.com/iw-cc/command/iw.base.logout
type	dom=document.forms['iw_login_external_user'].elements['iw_user']	testuser
type	dom=document.forms['iw_login_external_pwd'].elements['iw_password']	testpassword
select	document.forms['iw_login_external_options'].elements['iw_which_ui']	value=ccpro
select	document.forms['iw_login_external_options'].elements['iw_role']	value=editor
clickAndWait	link=Login

I wish anyone who tries automatic regression testing of TeamSite the very best of luck. It's a pig, a nightmare, but it is possible.

ads66

this is really a good post. Thanks for the valuable inputs. Just had a question - will Winrunner do the job? Haven't tried it but just had it as a second thought
Thanks,
A

Migrateduser

Hi Lozza -

Have you by any chance experiemented with the Selenium IDE plug-in for Firefox? I've been messing about with it a bit, and it seems to work fine for almost everything I've tried except for the javascript menus. Unfortunately, it won't doesn't seem to let one edit the test cases by hand from within the UI. I suspect that I could save out the test case, edit the xml, and get it to work, but if anyone had a better path forward, I'd appreciate it.

Cheers,
Rob

Lozza

The source tab in Selenium IDE seems to do what you want (v 1.0 beta 2)

I'm having a bit more fun with Selenium and TeamSite today, 3 years after my last post. I think I must have annoyed the gods. Here are some more tips that I've picked up while playing with Selenium and TeamSite:

Logout First

Because TeamSite will remember a user's session, tests should always start by calling the logout page, e.g.:

openAndWait http://teamsite-url/iw-cc/command/iw.reportingui.logout

Then, script the entering of the username, password, selecting the role and click the Login link:

type iw_user username
type iw_password password
select iw_role Master

Go Direct

Don't bother trying to navigate the DHTML menus. Really, it's horrendous\! Instead where possible you can access the internal TeamSite URLs directly. For example:

Create a new DCR:
openAndWait [http://teamsite-url/iw-cc/command/iw.ccpro.create_form?vpath ... etc

Navigate to a branch:
openAndWait http://teamsite-url/iw-cc/command/iw.ccpro.filesys?vpath=path_to_branch

Get the status of a job:
openAndWait http://teamsite-url/iw-cc/command/iw.ccpro.job_details

You get the idea.

Dynamic Content

Sometimes you'll find that a test will work, and other times it will not (particularly if you're running it at full speed). This isn't ideal, your test should be repeatable. Its success should not be dependent on the speed, or lack thereof, of the TeamSite box.

With most applications you can wait for the page to load completely before moving on to access elements on that page. This is easier said than done with TeamSite, because many pages are loaded with content dynamically, after the initial page or frame load has taken place. This is, frankly, a bit of a 'mare. However there are techniques you can use to get around this.

It's all fun, fun, fun!