在SE工作的7年中，有5年都在和UI自动化打交道。应该说对这块儿算是比较熟悉了。
早年间用AT命令控制feature phone做UI测试，后来随着android兴起，SE的测试工具沿用了类似于AT命令控制的原理来进行测试。
可以说SE的UI自动化测试平台在业内应该是我见过的最强大和最完善的，同时也是搭建成本最高昂的测试平台。没有之一。
言归正传，让我们来讨论下现有Android UI自动化测试的两种实现方法。
第一种是比较常见的apk植入式测试，将测试用例装入apk中，推入android设备进行执行。
第二种比较少见的是PC-agent，步进通信式测试，将原子方法装入apk或者jar包中，推入android设备。测试用例的执行在PC端，PC和android设备中的agent不停通信，最终实现测试。
两种方法各有优缺点。
植入式方法的优点是：
l 不需要进行PC通信，支持离线测试，对PC的依赖比较小。
l 对于由研发转测试的同学来说上手很快。
l Google提供的一些方法和系统契合度高。
缺点也很明显。
n 因为缺乏和PC的通信，所以在交互性case上有很大缺陷。
n 需要编译，debug时很讨厌。
n 测试log离线时只能保存在手机中，对手机内存要求比较苛刻。（SE的手机发生一次dump就会有数百M的log。基本上dump个十来次手机内存就满了。。。）
n 如果测试程序本身有问题，会造成测试APK崩溃，测试容易意外中止。
步进方法的优点是
l 交互性case逻辑简单，而且易于控制。
l 可以通过脚本编写，不需要编译，随改随测。
l Log实时回传PC。PC端如果有足够强大的工具可以实时解析log，提供实时的测试报告。
l 测试用例本身有问题的时候，不会造成手机上的应用crash。测试可以继续进行。
步进方法的缺点是：
n 通信过于频繁，如果手机的通信模块有bug，很容易造成测试中断。
n 依赖于ADB,如果ADB不稳定的话会造成测试中断（早期会发生类似的问题，Android4.0以后很少见）
n 对PC极端依赖，对于空间和硬件成本要求比较高。
一般来说，做应用的厂商使用植入式的测试就完全足够了。而做系统的厂商，则必须考虑到交互测试的问题。
UI Automator 让混合测试变成可能：
UI Automator（简称UA，下同）的出现可以为两种方法做一个相对完美的统一。（UIAutomator的信息请参考官方网站，如何架设和使用我在这里不赘述了。）
UIAutomator本身是执行在手机端的，同时，UA的测试需要通过adb命令触发。而命令可以选择，触发一个case集，还是只触发某一个方法。这就让混合的方法成为了可能。
需要封装两套方法，第一套是用于测试单机的case。可以将这部分case分开给各个被测设备独立运行。
第二套就可以直接封一套类似于agent的方法。通过脚本不停调用方法来实现交互性测试。
第二套方法还可以封装一些比原子方法更大一些的方法来实现。这个要根据被测的UI变化程度来判断。
这样的方式可以避开大多数测试工具的缺陷，让测试工具优势最大化。
但是，这样的测试一定需要测试自动化工程师介入去修改测试执行逻辑。这一点我们之后会另开帖子讲。
