On 12 July 2012 09:58, Andy Doan <[email protected]> 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? > > I guess I have two questions: > 1) can you describe what the install_black-box_test action would look like? > > 2) 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. > >> 2. wait_black_test_finish >> will loop to check until there is no entry in TODO and TESTING >> also will check if the test framework is running, if it is not in >> ps and there are still test to be run, will invoke it to run. >> show the output of the running test >> 3. collect_test_result >> parse and upload to lava >> ------------------------------------------------------------ >> >> *Related BPs* >> >> 1. lava side: >> >> https://blueprints.launchpad.net/lava-dispatcher/+spec/black-box-test-actions >> 2. android-side: >> >> https://blueprints.launchpad.net/linaro-android/+spec/support-blackbox-test >> >> Thanks, >> Yongqin Liu >> >> >> >> _______________________________________________ >> linaro-validation mailing list >> [email protected] >> http://lists.linaro.org/mailman/listinfo/linaro-validation >> > > -- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog _______________________________________________ linaro-validation mailing list [email protected] http://lists.linaro.org/mailman/listinfo/linaro-validation
