Hi Helge,
Sorry about the delay of just over 2 months in replying. I've been
busy with coursework and exams, which are now finished. I just have
my dissertation to go before I graduate in July, which will take up
around 40 hours per week. I also need to be look at some way of
earning some money by then otherwise I won't be able to pay the rent
or buy some food.
In some ways I think this delay has been a good thing. After looking
at some of my site stats I came across <http://
vcltesttoolglue.sourceforge.net/>. This is a Java based ( I know Java
a lot better than the C varients :-D ) app for viewing and running
the OpenOffice.org testtool.
I'll comment more below.
On 28 Feb 2007, at 15:11, Helge Delfs wrote:
Hi Shaun,
Shaun McDonald wrote:
I would love to see such a tool to be produced. I would love to be
able
to upload a zip file of all my testtool results and compare them to
everyone elses testtool results.
I would be able to help towards this project, however until I
graduate
in July, I don't have much time to spend on the OpenOffice.org
project.
However I could set the ball rolling, by starting to design the
system
on the wiki.
pleasent to hear that you are interested and willing to help the
community start creating such a valuable project. As you may have read
on the list I was the initiator and developer of a project named
'QA-Statuspages' inside SUN to have all our results of automated tests
collected and evaluated. I would like to give a quick overview of what
we think the requirements should be met to realize such a project as
measured by our experience.
1. Hardware
A server running a webserver, database-server and has scripting
enabled.
Maybe SAMP or LAMP (depends on your OS)
If vcltesttoolglue has been designed using the MVC pattern then I
would recommend using JSP. This would allow for a reuse of the model
code. I have used this previously in a project. After the initial
planning both the server (web interface) and the Java application
worked well together with good code reuse between the server and
client. The programming was also simpler once you got your head
around the idea of having the code and display different.
2. CVS
This server should maintain a complete tree of automated tests from
CVS
and should be updated in a (to be defined) time range to have
always an
up-to-date state of all testscripts
Storing the version number of the scripts that were used will be
useful. However this will cause an issue for when someone has done
modifications to the code for testing. One such example is the
database scripts and Mac OS X.
What is the current status of the CVS to SVN switch? Would it be
better to wait for that to use the SVN version numbers?
I have been working with CVS data for my dissertation, so getting the
CVS version numbers shouldn't be a problem. We just have to make sure
that the files haven't been modified from the checkout.
3. Database
A database server to host the data would be the best to work with,
because there will be an amount of data to be collected. As announced
some time ago, I would appreciate to make our database model available
to the community. We use mysql.
Some maybe helpful suggestions how our environment works.
- All information about testscripts (bas- and inc-files, testcases,
subs, documentation and so on) is collected and processed by a script
and committed to the database. (point 2.)
This will need to be easily kept up to date through the updates from
the CVS changes. Using a parser from the mail from the CVS change
mail from the relevant module should work.
- All testresults and -information of automated tests are processed by
testtool, written to text-files and committed to the database. For
further information see documentation in testtool-script
'qatesttool/global/inc/status.inc' This file is responsible to collect
and process data created during automated testrun. There will be a
script needed to submit collected data to the database.
And what happens if someone is running offline? They should still be
able to upload the results later, possibly from another machine. The
fact a test has been done offline or online could make a difference
for some of them, therefore it should be stored.
Now you have all information needed to create pages to evaluate
testresults.
Some features of our environment:
- Testresults grouped by platform
- Testresults grouped by application
- Testresults for pre-selected application
- Detailed testresults for a specific autotest
Please elaborate on what you mean by an autotest. It sounds very
similar to a testcase.
- Detailed testresults of a specific testcase
- Documentation of a testcase
- Compare results of automated tests in CWS with results from MWS
and so on.
Is this CWS/MWS information stored in all builds by default? Is it
stored in the result files currently?
I hope I was able to give you a short overview and some tipps to
make it
easier to start this project. If you have any questions don't hesitate
to ask.
I'm now just hoping that I will actually have time to do system
design and implementation. I'd be happy to work with Thorsten (not
sure which one) to bring both these two projects together.
Shaun
P.S. I haven't yet looked at the code for vcltesttoolglue by Thorsten.
___________________________________________________________
Try the all-new Yahoo! Mail. "The New Version is radically easier to use" The Wall Street Journal
http://uk.docs.yahoo.com/nowyoucan.html
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
