Re:[OpenSTA-devel] Re: Re: Codemax

[Federico T. <ft...@fi...>]

Ok, thanks for your comments (all)

> I'd like to request a slightly different feature (if I understand you
> correctly): Saving a page should be explicitly triggered by the script
> whenever the script would like to save a response - not on HTTP errors
> in general: I believe that load tests can easily and correctly test that
> state 404 is returned by the application. On the other hand if the page
> is returned with http-state 200 but contains unexpected content (e.g. an
> application error message) the script should be able to save this
> unexpected content.

> Presumably you have done some sort of conditional before your:
>   FAIL TEST-CASE
> Why not just LOG the error (or BODY contents) before doing the fail.

> How are the "test cases" defined?
> Do the pages get written out each to their own file, or in a log?

> If you just want to do it by HTTP Code then this would be relatively
> easily done in SCL - except if you want them writing out to seperate
> files, or if they are longer than 64K...

I will explain a little more.
In some cases, in a execution I see that the server return
aplication's errors and so the test case fail. If I want to know why
it fails, what try to say me the aplication, i can't.
For example, to do this to one VU I use BView, because I can view the
pages returned by the aplication. It's allright. But if I run the
script with two VU and there are problems, because the aplication
fails with concurrents users (for example too), I'd like to view the
pages with error to detect the error.
The easiest form to do this is that OpenSTA save this pages automatically.
I hope that you understand me.


> Your description makes me think of one worthwhile change that could
> probably be made fairly easily and is unlikely to upset any existing
> users:
>
> If after doing a GET/POST you try to pull something from the BODY
> content returned using:
>   LOAD RESPONSE_INFO BODY ON ConId INTO VarName, WITH DomIdentifier
>
> And the DomIdentifier does not match the structure of the content
> returned, then perhaps it would be nicer (rather than falling on its
> face with "unresolved variable" as it does now) if the whole BODY
> could be logged somewhere or placed in a variable.
>
> Of Course you can do something like this now by saying:
>   LOAD RESPONSE_INFO BODY ON ConId INTO VarName, &
>     WITH DomIdentifier, RETURNING STATUS RetStat
>   IF (RetStat < 0) THEN
>     LOAD RESPONSE_INFO BODY ON ConId INTO VarName
>     LOG VarName
>   ENDIF
> but perhaps something more elegant and automatic would be much more
> useful.

Ok, thats a good idea, that could helpme with other problems, but it
isn't what I want.



> > Then I want to investigate how to work with SOA and WebService, but
> > this will be in the future.
>
> I think you'll find lots of people interested in this type of work
> and ideas that make testing this type of use of HTTP easier or more
> complete will be most welcomed.

Ok, thats true, but for now I dont know a lot about so I'll try on
this in the feature.



> > I have implement a couple of tools in Java to do some activities
> > that can be done automaticaly.
> > For example, a tool to refresh the script's parameters files
> > (because after runing a test there are data that is no more valid,
> > so we have to repeat the SQL and export the result to the script's
> > parameters files to can run again)
> > I would like to integrate this funcionality to OpenSTA.
>
> The ability to run "tools" that can return your test system to its
> baseline standard either at the end or prior to starting a test, is a
> problem that many people have solved in many different ways.  Ideas
> of ways to make these tasks generically easier to automate within
> OpenSTAs toolset would be welcomed.

I supouse that you like me parametrice your scripts, and get your
values from file.
This files you have to generate with some data from DataBase with the
corresponding SQL.
I have 10 .fvr with parameters. After each execution I have to refresh
the contenent of this 10 archives. My tool gets the sql from a file
(acording how you configure a XML), and execute this and save the
result in the corresponding .fvr.
Before i made the tool, I take 10 minutes to do this job, and now I
take 1 second to press the buton.
I made this and anothers tools in java, but could be better that we
can integrate all of this to openSTA.


thks to all
greetings
FedeFede