小心！做UI自动化一定要跨过这些坑

楚杰

2017年03月24日

一、引子

UI自动化，在移动互联网时代的今天，一直都是在各大测试测试社区最为火爆的一个TOPIC。甚至在测试同行面前一提起自动化，大家就会自然而然的问：“恩，你们是用的什么框架？appium？还是robotium？”
其实在笔者看来，UI自动化是一个ROI较低的测试项（ROI即return on investment，中文意思是投资回报率）。但UI自动化相比接口自动化、白盒测试等，它更贴近手工业务测试行为。对于刚起步测试左移、效率提升的团队来说，是最迅速的切入点，也是广大黑盒tester，提升自身技术能力的起跑线。笔者接触UI自动化一年多，兼顾业务测试的同时断断续续地投入，曾经无数次的想放弃：“才刚写完用例，怎么开发大哥又改了UI了？”
“维护这些破用例的时间，都够我手工测三遍了，真的有意义么？”

“测试框架自己有bug，我改用例也没用啊……”

“我调试的时候这个用例还是通的，放到daily里面跑就不通，到底怎么回事嘛！”

“adb怎么这么不稳定啊，老是断！！！”

“怎么跑着跑着就crash了，到底是被测应用有问题，还是测试代码有问题啊？”

“明明界面上有这个元素，怎么就是查不到呢？”

“这破手机，能不能别老是系统弹框……”

“这手机真是渣，adb screencap截个图，居然要三分钟才返回！”

“这些控件都没有id，没有text，层级还三天两头改，要我怎么查……”

“查了这么多论坛，怎么就没有人遇到过类似的问题呢？”

……

这些问题让笔者一度怀疑，UI自动化这个TOPIC，是不是根本没用，只是tester为了涨薪，或者为了摆脱重复无聊的手工业务测试，而YY出来自我欺骗的。

二、问题分类及目标明确

笔者将以上所有的问题简单分成三类：设计类、环境类、细节类。一个好的设计模式，能够避免一部分问题；一套好的环境，可以让我们从乏味的维护工作中解脱；精益求精的细节，让测试用例更加可靠稳定。

图一UI自动化常见问题

填掉这三类坑，基本上就获得了一套低成本高产出、少量维护、稳定可靠的UI自动化用例集。

三、设计类问题分析与解决

“才刚写完用例，怎么开发大哥又改了UI了？”
“测试框架自己有bug，我改用例也没用啊……”这类问题，我们需要从根上治。UI自动化开发，也应该是严谨的开发工作，它也需要设计模式，也是磨刀不误砍柴工。这里的设计，主要包括选工具、框架分层等。很多前辈都分析过UI自动化各类工具的优缺点，对工具选用笔者不再赘述。主要依托uiautomator来介绍下笔者认为比较巧妙的用例框架设计。

1、优化测试代码框架

无论你选择appium、uiautomator、robotium还是espresso，刚入门时，看到的sample应该大致都是这样的。