[KVM-AUTOTEST PATCH v2 3/3] KVM test: add AutoIt test to kvm_tests.cfg.sample

[KVM-AUTOTEST PATCH v2 3/3] KVM test: add AutoIt test to kvm_tests.cfg.sample

[Michael Goldish]

Signed-off-by: Michael Goldish <mgoldish@redhat.com>
---
 client/tests/kvm/kvm_tests.cfg.sample |   12 +++++++++++-
 1 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/client/tests/kvm/kvm_tests.cfg.sample b/client/tests/kvm/kvm_tests.cfg.sample
index 12e907b..05a1ca7 100644
--- a/client/tests/kvm/kvm_tests.cfg.sample
+++ b/client/tests/kvm/kvm_tests.cfg.sample
@@ -126,6 +126,16 @@ variants:
         kill_vm_gracefully = no
         extra_params += " -snapshot"
 
+    - autoit:       install setup
+        type = autoit
+        cdrom = windows/autoit.iso
+        autoit_binary = D:\AutoIt3.exe
+        autoit_script_timeout = 600
+        autoit_script_params =
+        variants:
+            - notepad:
+                autoit_script = autoit/notepad1.au3
+
     - shutdown:     install setup
         type = shutdown
         kill_vm = yes
@@ -147,7 +157,7 @@ variants:
 variants:
     # Linux section
     - @Linux:
-        no timedrift
+        no timedrift autoit
         shutdown_command = shutdown -h now
         reboot_command = shutdown -r now
         status_test_command = echo $?
-- 
1.5.4.1

Re: [KVM-AUTOTEST PATCH v2 3/3] KVM test: add AutoIt test to kvm_tests.cfg.sample

[Cao, Chen]

On Tue, Aug 11, 2009 at 03:10:44PM +0300, Michael Goldish wrote:
> Signed-off-by: Michael Goldish <mgoldish@redhat.com>
> ---
>  client/tests/kvm/kvm_tests.cfg.sample |   12 +++++++++++-
>  1 files changed, 11 insertions(+), 1 deletions(-)
> 
> diff --git a/client/tests/kvm/kvm_tests.cfg.sample b/client/tests/kvm/kvm_tests.cfg.sample
> index 12e907b..05a1ca7 100644
> --- a/client/tests/kvm/kvm_tests.cfg.sample
> +++ b/client/tests/kvm/kvm_tests.cfg.sample
> @@ -126,6 +126,16 @@ variants:
>          kill_vm_gracefully = no
>          extra_params += " -snapshot"
>  
> +    - autoit:       install setup
> +        type = autoit
> +        cdrom = windows/autoit.iso
I am wondering what is the advantage of using .iso to store the binary
files. I think it might be hard to maintain the (scripts/binary)
files.
is it possible to pass a directory to run_autoit()?

> +        autoit_binary = D:\AutoIt3.exe
> +        autoit_script_timeout = 600
> +        autoit_script_params =
> +        variants:
> +            - notepad:
> +                autoit_script = autoit/notepad1.au3
> +... blahblah...

Besides, I think we may use staf framework to send command to MS
Windows
to run autoit scripts, it would be easier to control the status of the
autoit process.

what is your suggestion?

Thank you.


Regards,

Cao, Chen
2009/08/12

Re: [KVM-AUTOTEST PATCH v2 3/3] KVM test: add AutoIt test to kvm_tests.cfg.sample

[Michael Goldish]

----- "Chen Cao" <kcao@redhat.com> wrote:

> On Tue, Aug 11, 2009 at 03:10:44PM +0300, Michael Goldish wrote:
> > Signed-off-by: Michael Goldish <mgoldish@redhat.com>
> > ---
> >  client/tests/kvm/kvm_tests.cfg.sample |   12 +++++++++++-
> >  1 files changed, 11 insertions(+), 1 deletions(-)
> > 
> > diff --git a/client/tests/kvm/kvm_tests.cfg.sample
> b/client/tests/kvm/kvm_tests.cfg.sample
> > index 12e907b..05a1ca7 100644
> > --- a/client/tests/kvm/kvm_tests.cfg.sample
> > +++ b/client/tests/kvm/kvm_tests.cfg.sample
> > @@ -126,6 +126,16 @@ variants:
> >          kill_vm_gracefully = no
> >          extra_params += " -snapshot"
> >  
> > +    - autoit:       install setup
> > +        type = autoit
> > +        cdrom = windows/autoit.iso
> I am wondering what is the advantage of using .iso to store the
> binary
> files. I think it might be hard to maintain the (scripts/binary)
> files.
> is it possible to pass a directory to run_autoit()?

- I don't think it's too much trouble to maintain one big ISO that
  will serve all Windows tests.  I think we should start documenting
  its contents in the wiki.
  (Currently, by default, each test that requires a binary uses a
  different ISO file (rss.iso, vlc.iso, autoit.iso) but I think it's
  a good idea to put everything in a single ISO.)

- qemu doesn't directly read from directories, as far as I know.
  It requires an image file (ISO).

- We currently don't support sending files to all Windows guests.
  (We have no solution for Vista and 2008, which are quite important,
  and the solution I'm currently aiming for is adding send/receive
  functionality to rss.exe.)

> > +        autoit_binary = D:\AutoIt3.exe
> > +        autoit_script_timeout = 600
> > +        autoit_script_params =
> > +        variants:
> > +            - notepad:
> > +                autoit_script = autoit/notepad1.au3
> > +... blahblah...
> 
> Besides, I think we may use staf framework to send command to MS
> Windows
> to run autoit scripts, it would be easier to control the status of
> the
> autoit process.

What advantages does STAF have?  I don't think we lack control over the
AutoIt process, especially since by default, rss.exe kills all processes
(AutoIt in this case) started by a session when that session exits.
This can also be done manually, in case rss.exe isn't used, but I left
that to a future patch.

STAF is non-interactive, which means working with it will be different
from working with SSH, Telnet or rss.exe.  Do you suggest that we use
STAF for everything, or just for the AutoIt tests?
Using it for everything means we wouldn't have shell interactivity;
using it for AutoIt makes sense only if STAF is really that much better
for AutoIt tests than regular interactive shells.

> what is your suggestion?
> 
> Thank you.
> 
> 
> Regards,
> 
> Cao, Chen
> 2009/08/12

Thanks,
Michael

Re: [KVM-AUTOTEST PATCH v2 3/3] KVM test: add AutoIt test to kvm_tests.cfg.sample

[Cao, Chen]

On Wed, Aug 12, 2009 at 05:44:34AM -0400, Michael Goldish wrote:
> 
> ----- "Chen Cao" <kcao@redhat.com> wrote:
> 
> > On Tue, Aug 11, 2009 at 03:10:44PM +0300, Michael Goldish wrote:
> > > Signed-off-by: Michael Goldish <mgoldish@redhat.com>
> > > ---
> > >  client/tests/kvm/kvm_tests.cfg.sample |   12 +++++++++++-
> > >  1 files changed, 11 insertions(+), 1 deletions(-)
> > > 
> > > diff --git a/client/tests/kvm/kvm_tests.cfg.sample
> > b/client/tests/kvm/kvm_tests.cfg.sample
> > > index 12e907b..05a1ca7 100644
> > > --- a/client/tests/kvm/kvm_tests.cfg.sample
> > > +++ b/client/tests/kvm/kvm_tests.cfg.sample
> > > @@ -126,6 +126,16 @@ variants:
> > >          kill_vm_gracefully = no
> > >          extra_params += " -snapshot"
> > >  
> > > +    - autoit:       install setup
> > > +        type = autoit
> > > +        cdrom = windows/autoit.iso
> > I am wondering what is the advantage of using .iso to store the
> > binary
> > files. I think it might be hard to maintain the (scripts/binary)
> > files.
> > is it possible to pass a directory to run_autoit()?
> 
> - I don't think it's too much trouble to maintain one big ISO that
>   will serve all Windows tests.  I think we should start documenting
>   its contents in the wiki.
>   (Currently, by default, each test that requires a binary uses a
>   different ISO file (rss.iso, vlc.iso, autoit.iso) but I think it's
>   a good idea to put everything in a single ISO.)
> 
if the autoit scripts are changed, the iso has to be updated everytime
before testing, have you already got a good solution for this?

> - qemu doesn't directly read from directories, as far as I know.
>   It requires an image file (ISO).
> 
> - We currently don't support sending files to all Windows guests.
>   (We have no solution for Vista and 2008, which are quite important,
>   and the solution I'm currently aiming for is adding send/receive
>   functionality to rss.exe.)
> 
> > > +        autoit_binary = D:\AutoIt3.exe
> > > +        autoit_script_timeout = 600
> > > +        autoit_script_params =
> > > +        variants:
> > > +            - notepad:
> > > +                autoit_script = autoit/notepad1.au3
> > > +... blahblah...
> > 
> > Besides, I think we may use staf framework to send command to MS
> > Windows
> > to run autoit scripts, it would be easier to control the status of
> > the
> > autoit process.
> 
> What advantages does STAF have?  I don't think we lack control over the
> AutoIt process, especially since by default, rss.exe kills all processes
> (AutoIt in this case) started by a session when that session exits.
> This can also be done manually, in case rss.exe isn't used, but I left
> that to a future patch.
> 
> STAF is non-interactive, which means working with it will be different
> from working with SSH, Telnet or rss.exe.  Do you suggest that we use
> STAF for everything, or just for the AutoIt tests?
> Using it for everything means we wouldn't have shell interactivity;
> using it for AutoIt makes sense only if STAF is really that much better
> for AutoIt tests than regular interactive shells.
> 
I meant STAF for AutoIt only.
An advanced rss.exe may be the ultimate solution for MS Windows,
and life would be much easier.

but before that, we may also use some other tools to send file to guests,
and STAF to control the autoit tests. we just need to launch the test
and query the status, STAF is enough.

Nevertheless, I'm eager to see the advanced rss.exe.

Thank you.
 

Regards,

Cao, Chen
2009/08/12

Re: [KVM-AUTOTEST PATCH v2 3/3] KVM test: add AutoIt test to kvm_tests.cfg.sample

[Michael Goldish]

----- "Chen Cao" <kcao@redhat.com> wrote:

> On Wed, Aug 12, 2009 at 05:44:34AM -0400, Michael Goldish wrote:
> > 
> > ----- "Chen Cao" <kcao@redhat.com> wrote:
> > 
> > > On Tue, Aug 11, 2009 at 03:10:44PM +0300, Michael Goldish wrote:
> > > > Signed-off-by: Michael Goldish <mgoldish@redhat.com>
> > > > ---
> > > >  client/tests/kvm/kvm_tests.cfg.sample |   12 +++++++++++-
> > > >  1 files changed, 11 insertions(+), 1 deletions(-)
> > > > 
> > > > diff --git a/client/tests/kvm/kvm_tests.cfg.sample
> > > b/client/tests/kvm/kvm_tests.cfg.sample
> > > > index 12e907b..05a1ca7 100644
> > > > --- a/client/tests/kvm/kvm_tests.cfg.sample
> > > > +++ b/client/tests/kvm/kvm_tests.cfg.sample
> > > > @@ -126,6 +126,16 @@ variants:
> > > >          kill_vm_gracefully = no
> > > >          extra_params += " -snapshot"
> > > >  
> > > > +    - autoit:       install setup
> > > > +        type = autoit
> > > > +        cdrom = windows/autoit.iso
> > > I am wondering what is the advantage of using .iso to store the
> > > binary
> > > files. I think it might be hard to maintain the (scripts/binary)
> > > files.
> > > is it possible to pass a directory to run_autoit()?
> > 
> > - I don't think it's too much trouble to maintain one big ISO that
> >   will serve all Windows tests.  I think we should start
> documenting
> >   its contents in the wiki.
> >   (Currently, by default, each test that requires a binary uses a
> >   different ISO file (rss.iso, vlc.iso, autoit.iso) but I think
> it's
> >   a good idea to put everything in a single ISO.)
> > 
> if the autoit scripts are changed, the iso has to be updated
> everytime
> before testing, have you already got a good solution for this?

The AutoIt test already sends the scripts to the guest at runtime.
Only the binaries need to be in an ISO.
The method of sending the scripts is slightly hackish (using echo),
but in my opinion it is robust and I don't expect it to cause any
trouble.

> > - qemu doesn't directly read from directories, as far as I know.
> >   It requires an image file (ISO).
> > 
> > - We currently don't support sending files to all Windows guests.
> >   (We have no solution for Vista and 2008, which are quite
> important,
> >   and the solution I'm currently aiming for is adding send/receive
> >   functionality to rss.exe.)
> > 
> > > > +        autoit_binary = D:\AutoIt3.exe
> > > > +        autoit_script_timeout = 600
> > > > +        autoit_script_params =
> > > > +        variants:
> > > > +            - notepad:
> > > > +                autoit_script = autoit/notepad1.au3
> > > > +... blahblah...
> > > 
> > > Besides, I think we may use staf framework to send command to MS
> > > Windows
> > > to run autoit scripts, it would be easier to control the status
> of
> > > the
> > > autoit process.
> > 
> > What advantages does STAF have?  I don't think we lack control over
> the
> > AutoIt process, especially since by default, rss.exe kills all
> processes
> > (AutoIt in this case) started by a session when that session exits.
> > This can also be done manually, in case rss.exe isn't used, but I
> left
> > that to a future patch.
> > 
> > STAF is non-interactive, which means working with it will be
> different
> > from working with SSH, Telnet or rss.exe.  Do you suggest that we
> use
> > STAF for everything, or just for the AutoIt tests?
> > Using it for everything means we wouldn't have shell interactivity;
> > using it for AutoIt makes sense only if STAF is really that much
> better
> > for AutoIt tests than regular interactive shells.
> > 
> I meant STAF for AutoIt only.
> An advanced rss.exe may be the ultimate solution for MS Windows,
> and life would be much easier.
> 
> but before that, we may also use some other tools to send file to
> guests,
> and STAF to control the autoit tests. we just need to launch the test
> and query the status, STAF is enough.

Everything you mentioned is already being done using rss.exe, except
for sending binaries to the guest.
The AutoIt test sends the script, launches it and queries the exit
status.
I can see why STAF is enough to control the tests, I just don't see how
it is better.

> Nevertheless, I'm eager to see the advanced rss.exe.
> 
> Thank you.
>  
> 
> Regards,
> 
> Cao, Chen
> 2009/08/12

Re: [KVM-AUTOTEST PATCH v2 3/3] KVM test: add AutoIt test to kvm_tests.cfg.sample

[Cao, Chen]

On Wed, Aug 12, 2009 at 07:29:25AM -0400, Michael Goldish wrote:
> 
> ----- "Chen Cao" <kcao@redhat.com> wrote:
> 
> > On Wed, Aug 12, 2009 at 05:44:34AM -0400, Michael Goldish wrote:
> > > 
> > > ----- "Chen Cao" <kcao@redhat.com> wrote:
> > > 
> > > > On Tue, Aug 11, 2009 at 03:10:44PM +0300, Michael Goldish wrote:
> > > > > Signed-off-by: Michael Goldish <mgoldish@redhat.com>
> > > > > ---
> > > > >  client/tests/kvm/kvm_tests.cfg.sample |   12 +++++++++++-
> > > > >  1 files changed, 11 insertions(+), 1 deletions(-)
> > > > > 
> > > > > diff --git a/client/tests/kvm/kvm_tests.cfg.sample
> > > > b/client/tests/kvm/kvm_tests.cfg.sample
> > > > > index 12e907b..05a1ca7 100644
> > > > > --- a/client/tests/kvm/kvm_tests.cfg.sample
> > > > > +++ b/client/tests/kvm/kvm_tests.cfg.sample
> > > > > @@ -126,6 +126,16 @@ variants:
> > > > >          kill_vm_gracefully = no
> > > > >          extra_params += " -snapshot"
> > > > >  
> > > > > +    - autoit:       install setup
> > > > > +        type = autoit
> > > > > +        cdrom = windows/autoit.iso
> > > > I am wondering what is the advantage of using .iso to store the
> > > > binary
> > > > files. I think it might be hard to maintain the (scripts/binary)
> > > > files.
> > > > is it possible to pass a directory to run_autoit()?
> > > 
> > > - I don't think it's too much trouble to maintain one big ISO that
> > >   will serve all Windows tests.  I think we should start
> > documenting
> > >   its contents in the wiki.
> > >   (Currently, by default, each test that requires a binary uses a
> > >   different ISO file (rss.iso, vlc.iso, autoit.iso) but I think
> > it's
> > >   a good idea to put everything in a single ISO.)
> > > 
> > if the autoit scripts are changed, the iso has to be updated
> > everytime
> > before testing, have you already got a good solution for this?
> 
> The AutoIt test already sends the scripts to the guest at runtime.
> Only the binaries need to be in an ISO.
> The method of sending the scripts is slightly hackish (using echo),
> but in my opinion it is robust and I don't expect it to cause any
> trouble.

it seems that this testcase cannot handle more one one .au3 files.
and i think it quite possible that there are testcases that require
two or more .au3 files, for reusing code or some other reasons.

> 
> > > - qemu doesn't directly read from directories, as far as I know.
> > >   It requires an image file (ISO).
> > > 
> > > - We currently don't support sending files to all Windows guests.
> > >   (We have no solution for Vista and 2008, which are quite
> > important,
> > >   and the solution I'm currently aiming for is adding send/receive
> > >   functionality to rss.exe.)
> > > 
> > > > > +        autoit_binary = D:\AutoIt3.exe
> > > > > +        autoit_script_timeout = 600
> > > > > +        autoit_script_params =
> > > > > +        variants:
> > > > > +            - notepad:
> > > > > +                autoit_script = autoit/notepad1.au3
> > > > > +... blahblah...
> > > > 
> > > > Besides, I think we may use staf framework to send command to MS
> > > > Windows
> > > > to run autoit scripts, it would be easier to control the status
> > of
> > > > the
> > > > autoit process.
> > > 
> > > What advantages does STAF have?  I don't think we lack control over
> > the
> > > AutoIt process, especially since by default, rss.exe kills all
> > processes
> > > (AutoIt in this case) started by a session when that session exits.
> > > This can also be done manually, in case rss.exe isn't used, but I
> > left
> > > that to a future patch.
> > > 
> > > STAF is non-interactive, which means working with it will be
> > different
> > > from working with SSH, Telnet or rss.exe.  Do you suggest that we
> > use
> > > STAF for everything, or just for the AutoIt tests?
> > > Using it for everything means we wouldn't have shell interactivity;
> > > using it for AutoIt makes sense only if STAF is really that much
> > better
> > > for AutoIt tests than regular interactive shells.
> > > 
> > I meant STAF for AutoIt only.
> > An advanced rss.exe may be the ultimate solution for MS Windows,
> > and life would be much easier.
> > 
> > but before that, we may also use some other tools to send file to
> > guests,
> > and STAF to control the autoit tests. we just need to launch the test
> > and query the status, STAF is enough.
> 
> Everything you mentioned is already being done using rss.exe, except
> for sending binaries to the guest.
> The AutoIt test sends the script, launches it and queries the exit
> status.
> I can see why STAF is enough to control the tests, I just don't see how
> it is better.
> 

Since there is no further demand, I cannot tell which is better now.
for now, we do no need to speed time to maintain STAF, while we can get
more features, if needed, with rss.exe. However, they are just auxiliary
tools, and, as a user, i just choose the one that makes things run.

And, Thank you for the detailed explaination.


Regards,
 
Cao, Chen
2009/08/13

Re: [KVM-AUTOTEST PATCH v2 3/3] KVM test: add AutoIt test to kvm_tests.cfg.sample

[Michael Goldish]

----- "Chen Cao" <kcao@redhat.com> wrote:

> On Wed, Aug 12, 2009 at 07:29:25AM -0400, Michael Goldish wrote:
> > 
> > ----- "Chen Cao" <kcao@redhat.com> wrote:
> > 
> > > On Wed, Aug 12, 2009 at 05:44:34AM -0400, Michael Goldish wrote:
> > > > 
> > > > ----- "Chen Cao" <kcao@redhat.com> wrote:
> > > > 
> > > > > On Tue, Aug 11, 2009 at 03:10:44PM +0300, Michael Goldish
> wrote:
> > > > > > Signed-off-by: Michael Goldish <mgoldish@redhat.com>
> > > > > > ---
> > > > > >  client/tests/kvm/kvm_tests.cfg.sample |   12 +++++++++++-
> > > > > >  1 files changed, 11 insertions(+), 1 deletions(-)
> > > > > > 
> > > > > > diff --git a/client/tests/kvm/kvm_tests.cfg.sample
> > > > > b/client/tests/kvm/kvm_tests.cfg.sample
> > > > > > index 12e907b..05a1ca7 100644
> > > > > > --- a/client/tests/kvm/kvm_tests.cfg.sample
> > > > > > +++ b/client/tests/kvm/kvm_tests.cfg.sample
> > > > > > @@ -126,6 +126,16 @@ variants:
> > > > > >          kill_vm_gracefully = no
> > > > > >          extra_params += " -snapshot"
> > > > > >  
> > > > > > +    - autoit:       install setup
> > > > > > +        type = autoit
> > > > > > +        cdrom = windows/autoit.iso
> > > > > I am wondering what is the advantage of using .iso to store
> the
> > > > > binary
> > > > > files. I think it might be hard to maintain the
> (scripts/binary)
> > > > > files.
> > > > > is it possible to pass a directory to run_autoit()?
> > > > 
> > > > - I don't think it's too much trouble to maintain one big ISO
> that
> > > >   will serve all Windows tests.  I think we should start
> > > documenting
> > > >   its contents in the wiki.
> > > >   (Currently, by default, each test that requires a binary uses
> a
> > > >   different ISO file (rss.iso, vlc.iso, autoit.iso) but I think
> > > it's
> > > >   a good idea to put everything in a single ISO.)
> > > > 
> > > if the autoit scripts are changed, the iso has to be updated
> > > everytime
> > > before testing, have you already got a good solution for this?
> > 
> > The AutoIt test already sends the scripts to the guest at runtime.
> > Only the binaries need to be in an ISO.
> > The method of sending the scripts is slightly hackish (using echo),
> > but in my opinion it is robust and I don't expect it to cause any
> > trouble.
> 
> it seems that this testcase cannot handle more one one .au3 files.
> and i think it quite possible that there are testcases that require
> two or more .au3 files, for reusing code or some other reasons.

OK, that makes sense.

I'll send a patch that lets users specify additional files to send in a
parameter named 'autoit_script_deps' or something like that.

In any case, there's plenty that can be done with single file scripts,
and I hope to see us get to the point where we actually need the multi-
file functionality.  We still have a long way to go from the sample
notepad1.au3 script.

> > 
> > > > - qemu doesn't directly read from directories, as far as I
> know.
> > > >   It requires an image file (ISO).
> > > > 
> > > > - We currently don't support sending files to all Windows
> guests.
> > > >   (We have no solution for Vista and 2008, which are quite
> > > important,
> > > >   and the solution I'm currently aiming for is adding
> send/receive
> > > >   functionality to rss.exe.)
> > > > 
> > > > > > +        autoit_binary = D:\AutoIt3.exe
> > > > > > +        autoit_script_timeout = 600
> > > > > > +        autoit_script_params =
> > > > > > +        variants:
> > > > > > +            - notepad:
> > > > > > +                autoit_script = autoit/notepad1.au3
> > > > > > +... blahblah...
> > > > > 
> > > > > Besides, I think we may use staf framework to send command to
> MS
> > > > > Windows
> > > > > to run autoit scripts, it would be easier to control the
> status
> > > of
> > > > > the
> > > > > autoit process.
> > > > 
> > > > What advantages does STAF have?  I don't think we lack control
> over
> > > the
> > > > AutoIt process, especially since by default, rss.exe kills all
> > > processes
> > > > (AutoIt in this case) started by a session when that session
> exits.
> > > > This can also be done manually, in case rss.exe isn't used, but
> I
> > > left
> > > > that to a future patch.
> > > > 
> > > > STAF is non-interactive, which means working with it will be
> > > different
> > > > from working with SSH, Telnet or rss.exe.  Do you suggest that
> we
> > > use
> > > > STAF for everything, or just for the AutoIt tests?
> > > > Using it for everything means we wouldn't have shell
> interactivity;
> > > > using it for AutoIt makes sense only if STAF is really that
> much
> > > better
> > > > for AutoIt tests than regular interactive shells.
> > > > 
> > > I meant STAF for AutoIt only.
> > > An advanced rss.exe may be the ultimate solution for MS Windows,
> > > and life would be much easier.
> > > 
> > > but before that, we may also use some other tools to send file to
> > > guests,
> > > and STAF to control the autoit tests. we just need to launch the
> test
> > > and query the status, STAF is enough.
> > 
> > Everything you mentioned is already being done using rss.exe,
> except
> > for sending binaries to the guest.
> > The AutoIt test sends the script, launches it and queries the exit
> > status.
> > I can see why STAF is enough to control the tests, I just don't see
> how
> > it is better.
> > 
> 
> Since there is no further demand, I cannot tell which is better now.
> for now, we do no need to speed time to maintain STAF, while we can
> get
> more features, if needed, with rss.exe. However, they are just
> auxiliary
> tools, and, as a user, i just choose the one that makes things run.
> 
> And, Thank you for the detailed explaination.
> 
> 
> Regards,
>  
> Cao, Chen
> 2009/08/13