Re: [OpenSTA-users] Transactions not submitted

[Daniel S. <da...@Op...>]

Anindya Chatterjee wrote:
> > I was able to identify the problem.  The script when recorded
> > used HTML body instead of form data.  That is what was creating
> > problem.

I sincerely doubt this was "your problem".  The SCL script created
by recording HTTP in OpenSTA is a near enough exact representation of
what happened (HTTP wise)  between the Web browser and server during
the recording.  Form data for a HTTP POST request *is* included in
the HTTP body ... it sounds like you don't really fully understand
what is going on with your app.

Chances are your "transactions" are not being submitted by your Web
application (not OpenSTA as OpenSTA presently only talks HTTP and no
databas oriented protocol) because the HTTP replay in the script is
not maintaining its context(session) correctly.

> > However, the script never complained and went on executing
> > subsequent steps.  Shouldn't it stop at failure point?  That's
> > strange and very misleading.

Failure point?  Do you mean an HTTP failure point or the application
failure point?  The 2 are very different and it would only really be
possible for OpenSTA SCL scripts to be automatically generated to
exit on HTTP failures - which they don't currently.  Application
failures *have* to be coded by hand because of there very nature.

Olaf Kock wrote:
> What the script does and should do depends solely on the
> circumstances of what you want to test.  The notion of "failure"
> sometimes is "Return code 500", some other times it's the
> appearance of "no data has been changed" on a very pretty page
> coming back with Return code 200.  In other circumstances it might
> be the "not-appearance" of "Thank you for your comment" on the
> resulting page.

Good explanation Olaf.  Here's another example that I've found can
help people understand the difference between Web application and
HTTP failures:  On an imaginary but generic Web app you get a "Your
session has expired" message - this is a Web application error and
will normally be given with a HTTP 200 OK return code; the HTTP layer
was totally successful, the Web application lost (or expired) its
context.

> I'm thinking about a feature request to generate a comment into the
> head of the recorded script containing information that the script
> usually MUST be modified in order to get expected results.
> Probably this would get read more than any documentation... Daniel?
> ;-)

It would be nice if OpenSTA users attempted to understand how the
applications they are testing work, and what the toolset is doing to
test them ... maybe even make an attempt to read and understand the
documentation and FAQ ;)  But given that these are things that take
time, and problems and confusion can arrive quickly, it would be
fairly easy to add a header comment to recorded SCL scripts - how 
about something along the lines of:
 "This script was recorded by the OpenSTA Gateway version M.m.p.B.
  The unmodified script does not check for Web application or HTTP
  errors - you must hand code any return checking and flow logic if
  you want the replay to react to any potentially different returns
  than happened in the original recording session."
Do you think this could short circuit some potential confusion?  If
there's enough positive feedback for this sort of thing then we'll 
certainly make sure the next version contains something like it.

Cheers
/dan
-- 
Daniel Sutcliffe <Da...@Op...>
  OpenSTA part-time caretaker - http://OpenSTA.org/