On 9 March 2012 06:07, Zach Pfeffer <zach.pfeffer@linaro.org> wrote:
On 8 March 2012 00:01, YongQin Liu <yongqin.liu@linaro.org> wrote:
> Hi, Zach
>
> Here is what you write in the memo:
> https://docs.google.com/a/linaro.org/document/d/1mtaw5sVwVD4CD1fbAk0XU9jxIsA6Pion40lAR5sH-Vw/edit?hl=en_US
>
> 1. Pass TESTCOMMANDFILE1=a file from git via Android build
> 2. Pass TESTCOMMAND1=”command opt1 opt2” via Android build
> the command should be executed on the android, that means the command should
> be an android command. not a command of the host.
>
> 3. Be able to reboot the unit within one test
> 4. CTS
> 5. Pass a meta file back for parsing, or just a parser
>
>
> Here I can understand the 1st and the 2nd and the 5th.
>
> About the 3rd, we have talked about yesterday, the attachment file
> (talk.log) is the content of our talk yesterday.
> and I understand it like this:
>
>
> In some test case, there are the possibilities that the android image will
> reboot,
> and we should be able to handle such cases so that we can get the exact test
> result.
>
>
> and I thought about that again after the talk, there are also other
> possibility like reboot, such as power down, crash, freeze
> you mean all of these cases should be handled too?

Right. If a command in the command log causes the unit-under-test to
do any of those things, then the unit should be rebooted (in the case
of a hang) or the reboot should be sensed (in case the command caused
a reboot) and when the unit boots back up, LAVA would continue the
test on the command after the one that caused it to hang, reboot,
freeze, etc. LAVA should save the logs for the entire command file
run, including all hangs and reboots.

Thanks for your explanation. 
Now I know more about it.

> About the 4th one CTS, sorry, I am still not clear about what do you mean
> here by CTS,
> if possible, could you describe a test case about that?

Take a look at: http://source.android.com/compatibility/cts-intro.html

The suite is available here:
http://source.android.com/compatibility/downloads.html

We simply need to run the existing test cases:

http://dl.google.com/dl/android/cts/android-cts-4.0.3_r2-linux_x86-arm.zip
http://dl.google.com/dl/android/cts/android-cts-verifier-4.0.3_r1-linux_x86-arm.zip

Which are written against:

http://source.android.com/compatibility/4.0/android-4.0-cdd.pdf

About CTS, because the problem reported below 
http://code.google.com/p/android/issues/detail?id=24267 
 
we need to do some modification on our branch, 
and now we use a self compiled CTS binary to test.

And about the cts-verifier, below is the description written in the CDD file:
 The CTS Verifier is included with the Compatibility Test Suite, and is intended to be run by a human operator to test functionality that
cannot be tested by an automated system, such as correct functioning of a camera and sensors.
I will try to investigate if we can run it automatically, but I guess it will possible be not.

Thanks,
Yongqin Liu