Using environmental variables to run the tests is a good idea. There needs
to be a test configuration file that users edit and source before running
the tests. I would suggest a standard prefix to all the variables i.e.
PCPTESTENV or PCPTESTVAR.
Todd C. Davis
These are my opinions and absolutely not official opinions of Intel Corp.
-----Original Message-----
From: Zhang, Sonic [mailto:sonic.zhang@xxxxxxxxx]
Sent: Thursday, December 26, 2002 3:58 AM
To: kenmcd@xxxxxxxxxxxxxxxxx
Cc: PCP (E-mail)
Subject: RE: Are there any documents about the test suite?
Hi,
I am now running the PCP test suite. I find that some host names are
hard-coded in the test scripts, such as "moomba.melbourne.sgi.com" in case
77.
Because my test host has a different name, I have to revise each of
those name string manually. I think it is better to make all host name an
environment variable. What's your opinion?
I setup 3 machine for test, 2 of them have only 1 CPU while another
has 2. I install the test suite on all of them. There are a few failures, I
will send some *.out.bad files for your reference soon.
Thanks.
Sonic
-----Original Message-----
From: kenmcd@xxxxxxxxxxxxxxxxx [mailto:kenmcd@xxxxxxxxxxxxxxxxx]
Sent: 2002?12?25? 6:32
To: Zhang, Sonic
Cc: PCP (E-mail)
Subject: Re: Are there any documents about the test suite?
On Mon, 23 Dec 2002, Zhang, Sonic wrote:
> Hi,
>
> I am a user of PCP. I downloaded PCP test suite from the SGI FTP
> site.
> After I configure the test suite according to the README file and
> execute it, I find that some test cases fail.
> Are there any brief documents to describe what each case does? I
> didn't find any information in the test suite tar ball.
I'm afraid there is no additional information ... after the README, you'll
have to look at the individual test scripts and the source applications.
Failures typically fall into one of 3 categories ...
1. setup ... lots of tests fail in a similar fashion ... check the
availability of remote QA hosts running PCP and the PMDA installations.
2. generalization errors ... things work for us, but not for you because
of subtle differences in the environment, the platform, etc.
3. porting errors and functional failures.
For 1. you're on your own. For 2., we are interested in working with
you to generalize the tests so that they pass automatically in as many
environments as possible. For 3. you're on your own again.
If you send me a couple of the *.out.bad files I can help you decide
which classes of failures you're seeing.
|