图一 UI自动化常见问题联系方式：QQ：2747044651 网址http://zhengtuwl.com
填掉这三类坑，基本上就获得了一套低成本高产出、少量维护、稳定可靠的UI自动化用例集。
三、 设计类问题分析与解决
“才刚写完用例，怎么开发大哥又改了UI了？”
“测试框架自己有bug，我改用例也没用啊……”
这类问题，我们需要从根上治。UI自动化开发，也应该是严谨的开发工作，它也需要设计模式，也是磨刀不误砍柴工。这里的设计，主要包括选工具、框架分层等。很多前辈都分析过UI自动化各类工具的优缺点，对工具选用笔者不再赘述。主要依托uiautomator来介绍下笔者认为比较巧妙的用例框架设计。
1 优化测试代码框架
无论你选择appium、uiautomator、robotium还是espresso，刚入门时，看到的sample应该大致都是这样的。
图二uiautomator和espresso逻辑样例
问题在哪里？这些sample过于简单，都只教了我们UI自动化三元素：怎么查找元素、怎么操作元素、怎么校验结果。如果我们按照大多数分享帖或GitHub sample来写作自己的case。最后这种没有任何设计模式的框架，肯定会面临重构。拿上面的espresso来说：
假如action_save这个id开发改了，而你的用例集中，有30个步骤用例到了这个id，一个个去改，是不是要疯？
不厌其烦的重复写onView(withXX(xxx)).perform(click())这一长串，你不烦？
笔者是如何做的？分层设计和PageObjects模式。这两个方法，基本解决了笔者遇到的图一中所有的设计类问题。
图三 框架设计建议
按照图三进行分层设计后，得到如图四的测试代码包。
测试同行面前一提起自动化，大家就会自然而然的问：“恩，你们是用的什么框架？appium？还是robotium？”
其实在笔者看来，UI自动化是一个ROI较低的测试项（ROI即return on investment，中文意思是投资回报率）。但UI自动化相比接口自动化、白盒测试等，它更贴近手工业务测试行为。对于刚起步测试左移、效率提升的团队来说，是最迅速的切入点，也是广大黑盒tester，提升自身技术能力的起跑线。
笔者接触UI自动化一年多，兼顾业务测试的同时断断续续地投入，曾经无数次的想放弃：
“才刚写完用例，怎么开发大哥又改了UI了？”
“维护这些破用例的时间，都够我手工测三遍了，真的有意义么？”
“测试框架自己有bug，我改用例也没用啊……”
“我调试的时候这个用例还是通的，放到daily里面跑就不通，到底怎么回事嘛！”
“adb怎么这么不稳定啊，老是断！！！”
“怎么跑着跑着就crash了，到底是被测应用有问题，还是测试代码有问题啊？”
“明明界面上有这个元素，怎么就是查不到呢？”
“这破手机，能不能别老是系统弹框……”
“这手机真是渣，adb screencap截个图，居然要三分钟才返回！”
“这些控件都没有id，没有text，层级还三天两头改，要我怎么查……”
“查了这么多论坛，怎么就没有人遇到过类似的问题呢？”
……
这些问题让笔者一度怀疑，UI自动化这个TOPIC，是不是根本没用，只是tester为了涨薪，或者为了摆脱重复无聊的手工业务测试，而YY出来自我欺骗的。
二、 问题分类及目标明确
笔者将以上所有的问题简单分成三类：设计类，环境类，细节类。一个好的设计模式，能够避免一部分问题；一套好的环境，可以让我们从乏味的维护工作中解脱；精益求精的细节，让测试用例更加可靠稳定。
原文地址：http://blog.51cto.com/13914443/2156319