Android CTS testSeed分析

一、失败用例

最近CTS中遇到一个诡异的失败项testSeed，失败日志如下
那么这个测试用例是在测试什么呢？
结合日志和代码一起来看，可知道，这个测试用例是先上传了CtsMonkeyApp.apk，通过-s参数指定随机序列的seed为1337，执行monkey -s 1337 -v -p com.android.cts.monkey 500

12-21 13:33:48 I/192.168.1.2:5555: com.android.cts.monkey.SeedTest#testSeed FAIL 
junit.framework.ComparisonFailure: expected:<...h (ACTION_DOWN): 0:([1679.0,38]2.0)> but was:<...h (ACTION_DOWN): 0:([599.0,170]2.0)>
    at junit.framework.Assert.assertEquals(Assert.java:85)
    at junit.framework.Assert.assertEquals(Assert.java:91)
    at com.android.cts.monkey.SeedTest.assertOutputs(SeedTest.java:43)
    at com.android.cts.monkey.SeedTest.testSeed(SeedTest.java:27)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at junit.framework.TestCase.runTest(TestCase.java:168)
    at junit.framework.TestCase.runBare(TestCase.java:134)
    at com.android.tradefed.testtype.DeviceTestResult$1.protect(DeviceTestResult.java:81)
    at com.android.tradefed.testtype.DeviceTestResult.runProtected(DeviceTestResult.java:56)
    at com.android.tradefed.testtype.DeviceTestResult.run(DeviceTestResult.java:85)
    at junit.framework.TestCase.run(TestCase.java:124)
    at com.android.tradefed.testtype.DeviceTestCase.run(DeviceTestCase.java:117)
    at com.android.cts.tradefed.testtype.JarHostTest$TestRunnable.run(JarHostTest.java:235)
    at com.android.tradefed.util.RunUtil$RunnableNotifier.run(RunUtil.java:279)

二、原理分析

这个测试用例是测试seed一样的情况下，monkey随机产生的点击动作序列是一样的。归纳下就是计算机中的伪随机性在这个测试用例中失效了哇，纳尼？！

伪随机性（英语：Pseudorandomness）是指一个过程似乎是随机的，但实际上并不是。例如伪随机数（或称伪乱数），是使用一个确定性的算法计算出来的似乎是随机的数序，因此伪随机数实际上并不随机。在计算伪随机数时假如使用的开始值不变的话，那么伪随机数的数序也不变。伪随机数的随机性可以用它的统计特性来衡量，其主要特征是每个数出现的可能性和它出现时与数序中其它数的关系。伪随机数的优点是它的计算比较简单，而且只使用少数数值很难推算出计算它的算法。一般人们使用一个假的随机数，比如電腦上的時間作为计算伪随机数的开始值。

正向跟踪代码流程看看，测试用例是通过mDevice执行的shell命令，那么应该是和手动执行monkey命令是一样的

• mDevice是在哪赋值的？

通过试验后发现手动在命令执行monkey -s 1337 -v…命令后，再此跑测试用例就PASS了，这是怎么回事？我感觉应该是linux在成功通过seed随机出按键序列一次后，再次使用同样seed就一致了。

monkey命令走的是Monkey.java类函数main()，通过添加日志可以看到在命令行执行monkey时，串口会打印添加的日志

• 通过mDevice.executeShellCommand()执行命令，为啥没有打印添加的日志？

还是回到正向跟踪代码的流程，让我沉溺在代码的海洋中吧！
TestDevice的父类NativeDevice.executeShellCommand()调用AdbHelper.executeRemoteCommand()实际负责执行monkey -s 1337命令的

• 用到NIO的SocketChannel

通过NIO中的SocketChannel的read()、write()方法执行命令，并获得monkey命令输出，因而在执行testSeed用例时，monkey命令的输出不会在命令行窗口，而是通过SocketChannel被读到client端了

三、失败原因

-s 用于指定伪随机数生成器的seed值。如果seed相同，则两次Monkey测试所产生的事件序列也相同的。如下图所示

测试用例执行了两边monkey命令，seed相同，但是生成两个不同序列的随机事件，从而导致用例失败
失败原因很有可能是第一次执行monkey -s，随机事件还未生成完，第二次接着生成事件导致的。

四、解决方法

知道原因后相应解决方法就可以对症下药，具体怎么下药留给各位，本文主要记录测试原理和用到的知识点