incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zhe Liu <aliu...@gmail.com>
Subject Re: [DISCUSS]Next steps for automated testing
Date Fri, 15 Jun 2012 07:42:53 GMT
2012/6/15 Jürgen Schmidt <jogischmidt@googlemail.com>:
> On 6/15/12 8:31 AM, Zhe Liu wrote:
>> Hi all,
>> As mentioned before, I was working on a Java library to perform gui
>> testing. Actually it has been implemented on Symphony source code. It
>> involves 3 modules:
>> 1. https://svn-master.apache.org/repos/test/danielsh/symphony-import/symphony/trunk/main/test
>> It contains all testing scripts. Some JUnit testcases have been
>> written in the package "testcase". Smoke testing is re-implemented
>> based on the lib. We also developed some performance testing script,
>> but not include in svn.
>
> great news, we can really use such an improved automated test tooling.
>
> Do you oplan to include the performance test as well?
Yes!
>
>
>> 2. https://svn-master.apache.org/repos/test/danielsh/symphony-import/symphony/trunk/main/testcommon
>> It contains the low-level implementation to do GUI testing.
>> 3. https://svn-master.apache.org/repos/test/danielsh/symphony-import/symphony/trunk/main/testgui
>> It contains the common utilities used by uno api testing and GUI testing.
>> I also wrote one wiki page to introduce it.
>> http://wiki.services.openoffice.org/wiki/QA/vclauto
>
> I will take a look on it, thanks for the pointer
>
>>
>> I propose to do the following tasks next.
>> 1. Migrate the library to our AOO trunk. I has successfully used it to
>> test AOO 3.4 with some patch.
>> symphony/trunk/main/testcommon->ooo/trunk/main/testcommon
>> symphony/trunk/main/testgui->ooo/trunk/main/testgui
>> symphony/trunk/main/test->ooo/trunk/main/test   or
>> ooo/trunk/main/testoo  (Avoid to conflict with the test module that
>> already exists in AOO)
>
> you can create sub directories in main/test, I would avoid a new top
> level directory. But if it's easier don't hesitate to create one.
One sub-dir. It sounds better.

>
>> 2. Setup several testing machines to do build verification testing on
>> daily build. Post the result on somewhere(e.g. wiki, or maillist) .
>> The testing platforms includes:
>> Windows XP
>> Windows 7 32b/64b
>> Mac os x
>> Redhat
>> Suse
>> Ubuntu
>> ...? (pls suggest)
>
> When the tests running stable we can think about an integration in the
> build bots as well.
To run this kind of testing, graphics env is required. I don't know if
buildbot slaves meet the requirement.
Currently, we can use some external machines, periodically retrieve
builds from buildbot to local and then run testing. That also make us
cover more testing platforms.
>
>> 3. Continue to clean up the UNO API testing. I tried to run it and
>> found there are too many failures and some errors. I think API testing
>> is very valuable.It is essential to revive it.
>
> I agree and especially more complex API tests would be useful.
>
> Anyway great work and I am looking forward to see it in action and the
> first results.
>
> Juergen
>



-- 
Best Regards
>From aliuzhe@gmail.com

Mime
View raw message