On 12 July 2012 22: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
1. one item to indicate the command to run
2. 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:
1. 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
1. 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?
Yes, I think it's better we support the install action. Then we can install the test intended when we deploy android.
Of course as you said above, if the android to the same things during build, then it is unnecessary to specified the install action.
I guess I have two questions:
1) can you describe what the install_black-box_test action would look like?
I think at first we can make the install similar to the lava_android_test_install action now.
Like this:
{
"command": "install_android_black_box_test",
"parameters": {
"test": "monkey",
"command": ["monkey", $(OPTION), "500"],
"option": "-s 5",
"timeout": XXX,
"reboots_allowed": 3
}
}
I'd like the result directory and indicator directory are set in some configure file, not specified in the action.
With the above information, we could generate a simple indicator file only has the following line:
command="monkey -s 5 500"
And about the status whether the test is finished, we can use the directory structure I described above.writing the completion signal to the serial console would not be easy for some test.