Hi Marc (and Dennis who I guess must have emailed you directly),
Really appreciate your response and advice.
On these pages I don't get javascript errors when I run the script - only
when I open the saved pages, so thanks for the explanation of that. I'm
curious what would happen in the script if a page had a standard, harmless,
javascript error in it?
re the logs: There is not cruise.console.log.xml or anything like this on my
C:\ drive. I tried editing log4j.properties and uncommenting all the logging
lines, but can't find where the logs are actually written and not sure
whether this was a sensible thing to do anyway. Then I downloaded Ant (
1.7ORC) and ran it and suddenly millions of screens of output from such a
simple command line ("ant")!
This seems to show the problem as being that I run tests against an internal
host (aklia781:57106) which doesn't require a proxy, but the page causing
the problem is accessing https://ssl.google-analytics.com/urchin.js which is
not available without going through a proxy. However, Air NZ uses NTLM proxy
so I have been using ntlmaps-0.9.9 to give WebTest external access, but when
I try to set this up so it still allows access to the internal host by
doing:
<setproxy proxyhost="127.0.0.1" proxyport="5865" nonproxyhosts="aklia781"/>
the nonproxyhosts bit doesn't seem to work and I get an error 503 from
http://aklia781:57106/isbook_en_NZ/book/?";>http://aklia781:57106/isbook_en_NZ/book/Service
unavailable seems odd but is the same error I get if I remove the
nonproxyhosts bit.
Then I tried the WebTest proxy entry instead, nested in config element as
described in http://webtest-community.canoo.com/wiki/space/NTLM+Proxy+Patch but
of course it doesn't work saying "config does not support the nested proxy
element", which agrees with the manual and I guess means that Daniel
Gredler's patch never made it into the official version.
<http://webtest-community.canoo.com/wiki/space/NTLM+Proxy+Patch>Do you know
why that is? It sounds as though it may be what I need. Alternatively am I
doing something wrong with the Ant proxy command - particularly the
nonproxyhosts bit?
re the Automated Tools choice: I agree there is a required technical aspect.
Our goal is to set up the equivlent of what fitnesse calls "fixtures" i.e.
set up WebTest scripts that provide the "glue" to link test cases to the web
application, in a sufficiently generic way that non-technical testers, BAs
etc can modify not just the data used but the flow of the test, without
technical intervention. This approach is described quite well under the name
"Keyword Driven Approach" at http://www.kjross.com.au/smartest/. I would
only use a capture tool as an aid and indeed use WebTest Recorder this way.
regards,
John
On 11/23/06, Marc Guillemot <[EMAIL PROTECTED] > wrote:
Hi John,
I guess that you're original mail has been rejected from the mailing
list due to the attachments (I haven't looked at them either as it would
take me too much time).
Can you run you WebTest directly with ant rather than with the
webtest.bat script or look if a cruise.console.log.xml file has been
generated? The stacktrace I'm looking for should be displayed on the
console (or in the log file).
-----
@Denis:
is the execution log intentionaly hidden? Personally I use the
webtest.{bat|sh} scripts only to build webtest and dislike using them
when I run my own WebTests. If it is not the case, what about moving the
logger settings from the shell script to the cruise caller?
-----
The js errors you see when opening result files saved by WebTest are
probably normal as the references to external js files are lost. The js
error you get when running the tests is probably an other problem.
Concerning your automated test tools choice, I don't wont rail against
testing tools here but remember that test automation is a software
engineering activity. Non technical testers can surely generate some
tests that can be run but creating test suites that are easily
maintainable over a long time requires other skills. Captured script are
typically not really adaptable and require re-recording what is not the
best way to prevent for regression (we develop it a bit in our OOPSLA
abstract
http://webtest.canoo.com/webtest/manual/externalCitations/OOPSLA2006_WebTestAbstract.pdf
).
Marc.
John and Pip wrote:
> Hi Marc,
>
> All that I see in the DOS console is:
>
> C:\WebTest\doc\ISIS>webtest -buildfile tempTest.xml
>
> BUILD FAILED
> C:\WebTest\doc\ISIS\tempTest.xml:11: Canoo Webtest: R_1438.
> Test failed.
> Test step steps (C:\WebTest\doc\ISIS\tempTest.xml:13: ) null failed with
> message
> "Step[clickLink "Submit" (47/50)]: Script error loading page executing
> webtest
> at: clickLink Wrapped com.gargoylesoftware.htmlunit.ScriptException:
> Connection
> timed out: connect (Wrapper definition for javascript url#1)
> Source code:
> GargoyleWrapper8()"
>
> Total time: 50 seconds
>
> I've also attached the results.xml. I don't think there is any more
> useful detail here. Is there some other log file produced or some way to
> turn debug logging on?
>
> I've also attached the final "screen" capture file. I had neglected to
> mention that there is a javascript error when I open that file in a
> browserbut I doubt that has anything to do with it because the page
> actually must be getting submitted as I get a booking in the system.
> Webtest just doesn't seem to then get to the next page. Also hard to
> report the javascript error to the development team as a defect because
> it only appears in the saved WebTest HTML file, not in real use. I've
> shown this in screenshots in the Word doc attachment.
>
> re the href:
>
> The form is defined with:
> <form method="post" action="/isbook_en_NZ/book/reviewAndPurchaseCash.do"
> onsubmit="pleaseWait(); calChecksum(); return true;"
> id="reviewAndPurchaseCashForm">
>
> and the button/link to complete purchase as:
>
> <a
>
href="javascript:pleaseWait();calFormChecksum();MM_findObj('reviewAndPurchaseCashForm').submit();">
>
> <img src="../images/btnpurchase.gif"
> width="139" height="20" border="0"
> alt="Purchase Tickets" />
> </a>
>
> so I don't think there is much choice. The problem is the development
> team attempt to make these pages hard for robots to navigate (close to
> impossible in production by randomising control names) but I can get
> round it to some extent in test environment. However, asking them to
> modify code is expensive and I'd rather avoid it if at all possible.
>
> Another tool I'm looking at (QEngine) identifies this control with a map
> file entry:
> <ELEMENT ID="[this is the local name the tool uses so not related to the
> HTML]" alt="Purchase Tickets" browser=" IE6.0" class="NONE"
> formname="NONE" id="NONE" index="0" name="NONE"
> source="http://aklia781:57106/isbook_en_NZ/images/btnpurchase.gif
> < http://aklia781:57106/isbook_en_NZ/images/btnpurchase.gif>"
> sourceindex="359" tagName="IMG" title="NONE" tooltip="NONE"
value="NONE"/>
>
> so not sure whether I could refer to the image or better yet the alt tag
> rather than to the html in WebTest? Ah, I suppose this is where I would
> use the xpath parameter to clickLink right? I guess I could also put in
> a request to have alt added as an option to clickLink?
>
>
> thanks and regards,
> John
_______________________________________________
WebTest mailing list
[email protected]
http://lists.canoo.com/mailman/listinfo/webtest
