-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Uwe Salomon schrieb am Thu, 19 May 2005 07:30:50 +0200: <snip>
> Hmm, the question is: When will you have finished? But i would need the statistics of DStress over time to calculate that (bad description... i mean the numbers "count of test cases" and "count of successfull test cases", but from the past, i.e. "how many test cases did DStress have when dmd 0.99 (for example) was released"). This way we could estimate the future growth?

sample:
svn checkout -r "{2005-04-28}" http://dstress.kuehne.cn

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFCjEfA3w+/yD4P9tIRAmHvAKDD/AxXSvlU81M42bqvSpLIBqPGjgCfZ2o+
JKVVjxripp+bdjB22Dqdcys=
=gBHY
-----END PGP SIGNATURE-----

>> Hmm, the question is: When will you have finished? But i would need the
>> statistics of DStress over time to calculate that (bad description... i
>> mean the numbers "count of test cases" and "count of successfull test
>> cases", but from the past, i.e. "how many test cases did DStress have when
>> dmd 0.99 (for example) was released"). This way we could estimate the
>> future growth?
>
> sample:
> svn checkout -r "{2005-04-28}" http://dstress.kuehne.cn

Ok thanks i'll try to pull something out of it, especially regarding the "multiplication" of the test cases. You said one would have to examine the URI, because all test cases with the same URI belong to the same bug?

Thanks
uwe

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Uwe Salomon schrieb am Thu, 19 May 2005 08:16:03 +0200:
>>> Hmm, the question is: When will you have finished? But i would need the
>>> statistics of DStress over time to calculate that (bad description... i
>>> mean the numbers "count of test cases" and "count of successfull test
>>> cases", but from the past, i.e. "how many test cases did DStress have
>>> when
>>> dmd 0.99 (for example) was released"). This way we could estimate the
>>> future growth?
>>
>> sample:
>> svn checkout -r "{2005-04-28}" http://dstress.kuehne.cn
>
> Ok thanks i'll try to pull something out of it, especially regarding the "multiplication" of the test cases. You said one would have to examine the URI, because all test cases with the same URI belong to the same bug?

All test cases with the same URI belong to the same bug report and often describe - or are caused by - 1 to 3 bugs.

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFCjE3m3w+/yD4P9tIRAtQ/AKCityozjS5JuzD4PpI43H+9oU7wNgCfWwQq
PKxLrC9m+3nLGiYhtVh8Or4=
=sKoT
-----END PGP SIGNATURE-----

>>>> Hmm, the question is: When will you have finished? But i would need the
>>>> statistics of DStress over time to calculate that (bad description... i
>>>> mean the numbers "count of test cases" and "count of successfull test
>>>> cases", but from the past, i.e. "how many test cases did DStress have
>>>> when
>>>> dmd 0.99 (for example) was released"). This way we could estimate the
>>>> future growth?
>>>
>>> sample:
>>> svn checkout -r "{2005-04-28}" http://dstress.kuehne.cn
>>
>> Ok thanks i'll try to pull something out of it, especially regarding the
>> "multiplication" of the test cases. You said one would have to examine the
>> URI, because all test cases with the same URI belong to the same bug?
>
> All test cases with the same URI belong to the same bug report and often
> describe - or are caused by - 1 to 3 bugs.

Hmm. After some work i made a statistic showing the evolution of DStress... The PDF is 200k so i put it on my homepage:

http://www.uwesalomon.de/code/dstresseval/eval.pdf

In the directory there are also the files i used to gather that input (a dstresseval.d which reads the input of a grep on the dstress files, all commands are in auswerten.sh), just if you are interested... Now to the table in the PDF:

- 1st column is the date of the subversion checkout
- 2nd column is the number of *.d files in DStress
- 3rd column is the number of *.d files tested by DStressEval. Only the files with a @uri@ or @date@ could be tested, as you can see there are a lot without this designation.
- 4th column is the number of files which were determined to be independent. They have a different @uri@, or if they did not contain an @uri@ a different @date/author@ (but those are only 6 files, thus that won't break the statistic).
- 6th column is an extrapolation of the rate independent/total of the DStressEval files to the test cases total. This is somehow vague, because only 20-45% of the total test cases could be tested by DStressEval. Not sure what to do about that.

The diagram below depicts the number of total and independent testcases. As you can see, the independent test cases are stagnating (but note that the last column is not a full month yet). And at least for this month the total testcases seem to be stagnating as well? Hmm, well, everyone may interpret into this what he wants. I think there are a lot of redundant test cases that cover different variants of the same bug (or 2/3 bugs). Mostly they are all fixed together, still it is very useful to have them in DStress.

Ciao
uwe

> And at least for this month the total testcases seem to be stagnating as well?

I have to add here that the number of test cases is "stagnating", yes, but on a very high niveau. Impressive work, Thomas!

Ciao
uwe

Uwe Salomon wrote:
| Hmm. After some work i made a statistic showing the evolution of
| DStress... The PDF is 200k so i put it on my homepage:
|
| http://www.uwesalomon.de/code/dstresseval/eval.pdf
|

Link seems to be broken

Thomas

> | Hmm. After some work i made a statistic showing the evolution of
> | DStress... The PDF is 200k so i put it on my homepage:
> |
> | http://www.uwesalomon.de/code/dstresseval/eval.pdf
> |
>
> Link seems to be broken

Oops sorry, i somehow copied it wrong.

Ciao
uwe