On 15 July 2012 17:18, Michael Hudson-Doyle michael.hudson@linaro.org wrote:
Zach Pfeffer zach.pfeffer@linaro.org writes:
On 12 July 2012 09:58, Andy Doan andy.doan@linaro.org wrote:
On 07/12/2012 02:42 AM, YongQin Liu wrote:
Hi, All
Here just some thought about the implementation of black-box test. If you have any ideas, or something I missed, please give a comment. Anything will be appreciated.
*Glue between lava and android*
In android there is a directory /data/blackbox_tesxt/, under it are TODO, TESTING, DONE 3 direcories.
TODO: the flags for test that need to run will be put here
TESTING: the flags for test that are running will be put here.
normally, there should be only one entry. In the future will be more entries when we support test execution via thread
DONE: the flags for test that have been completed will
be put here
About the entry format, will use JSON or just key/value pair. but need to have the following two features
- one item to indicate the command to run
- other items used for pass information between android test tool and
lava job
*Black-box test framework on Android*
On android, a test framework will check the entries in TODO, and run the command indicated in the entry. Before the test is start to run, the framework will put the entry to TESTING, and after test finished will put the entry to DONE. when run the test command, this framework will run the command and pass the entry file as parameter.
The black-box test framework in android mainly do:
- invoked after boot up and home screen is displayed. also charge for prepare the test environment like unlock screen,
disable suspend 2. charging for invoking test command and changing the status of the each test
*Framework on LAVA*
Will have 2 actions
- install_black-box_test
I can see why you are proposing this. However, I'm wondering if this is what Zach was envisioning? ie - I thought the assumption was the android build would come pre-populated with these things installed. However, maybe we need this so we can support something like an AOSP build?
I guess I have two questions:
can you describe what the install_black-box_test action would look like?
Zach - are you okay with this approach?
I think these are interesting ideas. I like the idea of the files.
I think all of this is actually handled in the blackbox itself and the only thing that LAVA does is call a well-known function, then wait some time t, then reset the unit and read the output file at a well-known location. Everything else we'd handle on target.
But if we want to run blackbox tests on AOSP, we'll have to do _something_ in lava, right? Can that be as simple as installing an apk or something with adb?
Not really. We build AOSP from a copy of their manifest. It wouldn't be hard to just add the test stuff in.
Cheers, mwh