automated web testing advice

[Marc E]

Greetings all.

I'm seeking advice on a proper approach for automating web testing. My
ambitions are modest: I want to be able to programmatically go into a site,
click some links, submit some forms, and ensure nothing is broken.
occassionally i'll want to investigate the contents of a form field, change
form fields and submit and then investigate that fields were saved
appropriately, etc.

I'm doing this to test several web applications that are not written in
java. I have a product, and there's a version of the product for a number of
separate clients. Each of these versions then lives on a bunch of different
servers (dev, test, QA, staging, Prod), and I want to use these tests for
initial smoke testing of deployments.

Now, I can currently do all of this with httpunit and it's pretty fun to
write the tests. And since the functionality among the client apps is so
similar, I can write a single group of core tests and just point the test to
the different URLs...so I get high reuse.

The downside here is that if I go this route, i know i'll be the one stuck
building and maintaining all of the tests, and I'm not sure I want to take
that on.

I understand that there are "recorder" type tools for doing this sort of
thing, and if they are high quality, then other people could use them. But I
fear that with all the different apps and all the different environments,
these things might not scale well since we'd be recording the same set of
steps for each client app, etc. In addition, I understand that at least some
of these tools (Mercury TestDirector, from what i hear) uses the coordinates
for recording. So if a link moves, your test breaks. I do not know this for
certain...this is from someone who investigated this product for our company
several years ago and turned it down.

So...given these things, which I imagine has to be a pretty common scenario,
does anyone have any advice for proceeding? I don't mind writing and
maintaining the tests, but I'd hate to put all that time into it and then
hear "oh, dude, you could've just bought XYZ package and banged all that
stuff out in a few days and then all your other people could also help with
the test building"

Thanks for all advice.

Marc

 

[FrancisHeaney2]

Greetings all.

I'm seeking advice on a proper approach for automatingweb testing. My
ambitions are modest: I want to be able to programmatically go into a site,
click some links, submit some forms, and ensure nothing is broken.
occassionally i'll want to investigate the contents of a form field, change
form fields and submit and then investigate that fields were saved
appropriately, etc.

Since you do _not_ need to test Java, try the *free* iMacros for
Firefox from http://www.iopus.com/imacros/firefox/

It contains a STOPWATCH commands so you can even measure web page
response times and log them into a file. The same company also offers
some paid versions that can test Java and Flash applets, too. This is
what we use in our company. But it seems for your tasks the free
version is sufficient.

Francis

 

[Andy Dingley]

I'm seeking advice on a proper approach for automating web testing. My
ambitions are modest: I want to be able to programmatically go into a site,
click some links, submit some forms, and ensure nothing is broken.

Tsung / Erlang loook promising.

Like most of these things, initial setup is a manual pain, then future
regression is easy. Erlang's a language you can use to write your
tests, Tsung is a proxy that catches manual input and makes Erlang
scripts for you.

 

[alex]

Greetings all.

I'm seeking advice on a proper approach for automating web testing. My
ambitions are modest: I want to be able to programmatically go into a site,
click some links, submit some forms, and ensure nothing is broken.
occassionally i'll want to investigate the contents of a form field, change
form fields and submit and then investigate that fields were saved
appropriately, etc.

I'm doing this to test several web applications that are not written in
java. I have a product, and there's a version of the product for a number of
separate clients. Each of these versions then lives on a bunch of different
servers (dev, test, QA, staging, Prod), and I want to use these tests for
initial smoke testing of deployments.

Now, I can currently do all of this with httpunit and it's pretty fun to
write the tests. And since the functionality among the client apps is so
similar, I can write a single group of core tests and just point the test to
the different URLs...so I get high reuse.

The downside here is that if I go this route, i know i'll be the one stuck
building and maintaining all of the tests, and I'm not sure I want to take
that on.

I understand that there are "recorder" type tools for doing this sort of
thing, and if they are high quality, then other people could use them. But I
fear that with all the different apps and all the different environments,
these things might not scale well since we'd be recording the same set of
steps for each client app, etc. In addition, I understand that at least some
of these tools (Mercury TestDirector, from what i hear) uses the coordinates
for recording. So if a link moves, your test breaks. I do not know this for
certain...this is from someone who investigated this product for our company
several years ago and turned it down.

So...given these things, which I imagine has to be a pretty common scenario,
does anyone have any advice for proceeding? I don't mind writing and
maintaining the tests, but I'd hate to put all that time into it and then
hear "oh, dude, you could've just bought XYZ package and banged all that
stuff out in a few days and then all your other people could also help with
the test building"

Thanks for all advice.

Marc

You can also try SWExplorerAutomation (SWEA) from http://webiussoft.com.
SWEA can records tests and generate C# (very close to Java) test
script code.

 

[Marc E]

Thanks for the responses everyone.

i'm surprised that noone suggested looking at jameleon. looking at it, it
seems cool...i'm just wondering if anyone actually uses the thing.

i'll check out all your suggestions.