Re: [Ground-user] Grinder Headless Execution - automating test runs without the need for manual intervention

[Calum F. <cal...@gm...>]

Hi Ouray,

Did you mean for this email to come to the ground-user mailing list?
If you haven't posted this in the grinder-user mailing list then you
should as you are more likely to get an answer there.

I missed the fact that this came to the ground report mailing list and
not the grinder mailing list (emails from both go into the same
account) for some reason so apologies for the delay in response.

Cheers
Cal


On 24 May 2011 13:18, Ouray Viney <ou...@vi...> wrote:
> Hi All:
> I am looking for some advice/suggestions for the following test/business
> requirement.
> As a test engineer, I need to be able to run Grinder in such a way that does
> not require user intervention, in order to allow for unmanned testing.
> Example:
> I have 3 test runs that I need to execute.  I do not want to manually
> monitor the tests from the Grinder Console.
> Test methodology:
>
> Clean application logs
> Start-up application
> Test to ensure application is ready for load, avoid manual timing in scripts
> etc.
> Run a script (bash) that makes a call to grinder to start-up (headless -
> without the Grinder Console).
> Once the grinder run completes, harvest the required test artefacts and
> start back at bullet 1 to complete n runs.
>
> Psydo code for wrapper script, in this example a shell script will do:
> Description:  This script will run 3 tests, and follow my desired test
> methodology for each test run.
> TEST_NAME=Checkout
> TEST_RUNS=1 2 3
>
> for i in ${TEST_RUNS};
> do
>     # call application to startup
>     # call to validate that the application is ready for testing
>     # call to start resource monitoring on SUTs
>     # call grinder agent to start
>     # once grinder agent complets call
>     # call to stop application
>     # call to fetch logs
>     # call to delete old logs
>     # call to fetch resource logs on SUTs
> done
> Other options:
> - pass in dynamic grinder properties upon calling grinder agent to allow for
> changing the 1) script 2) duration 3) thread for example.
> Call to script (see Script: section below):
> ./script.sh grinder.useConsole=false grinder.threads = ${THREAD_COUNT}
> grinder.duration = ${TEST_DURATION}
> Script:
> <snippet>
> for args in $@; do JAVA_ARGS = "${JAVA_ARGS} -D${args}"
> $JAVA_HOME/bin/java -cp $CLASSPATH $JAVA_ARGS net.grinder.Grinder
> $GRINDER_PROPERTIES
> </snippet>
> My guess:
> - So far it seems that you can start an agent and tell it to start without
> the Grinder Console, which intrinsically tells the agent to run a particular
> script (as defined in the grinder.properties).  I have tested this with
> Grinder Stone, and it works great.
> My Question:
> - Is there any know reason why this is not a good idea?  Has anyone seen/see
> issues with this approach?
> - Are there any better suggestions?
> Any thoughts/comments are welcome.
> Kind Rgds,
> --
> Ouray Viney
> http://www.viney.ca
>
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
> _______________________________________________
> Ground-user mailing list
> Gro...@li...
> https://lists.sourceforge.net/lists/listinfo/ground-user
>
>