为什么很少有游戏公司做手游的UI自动化测试？ - 知乎7被浏览991分享邀请回答02 条评论分享收藏感谢收起标签：至少1个，最多5个
秉着想偷懒的原则和测试这块一直存在的诟病，空闲的时把苹果提供的UIAutomation研究了一番，心想这样就可以坐等APP自己跑完所有流程然后输出 carsh 报告。但是想象很丰满，现实很骨感，UiAutomation 并没有想象中那么的完美。
? + I 打开Instruments，选择 UiAutomation，基本界面就是这样
功能区域介绍:
① 开始、结束测试按钮，选择设备和项目菜单
② JS脚本编辑区，Trace Log 和 Editor Log显示区
③ 自动化测试时间线
④ 其他菜单页面
⑤ 脚本或是Log选择菜单
⑥ 自动生成JS脚本代码的开始、结束和停止按钮
看一个简单的测试例子，APP的界面上有一个UITextField，称之为A元素，Navigationbar有个rightItem，称之为B元素，点击rightItem会push到另一个VC
在④中选择一个空的脚本写入下列代码，对 JS 不了解的也不用当心，自动化测试的 JS 代码非常简单。
var target = UIATarget.localTarget();
var app = target.frontMostApp();
var window = app.mainWindow();
// 打印元素树
app.logElementTree();
? + R跑一下，②区域应该会自动切换到Log界面
Log打印出来的是当前界面的元素（UIAElement）树，同层级的元素会被包含到数组中，模拟用户操作其实就是对元素的操作，那么获取到元素才是关键。logElementTree()这个函数非常有用，在页面切换的时候记得要再次调用，以便找到你想要的元素
补充脚本：
var target = UIATarget.localTarget();
var app = target.frontMostApp();
var window = app.mainWindow();
app.logElementTree();
var textField = window.textFields()[0];
// 在 A 元素中输入122
textField.setValue("122");
// 停顿1秒
target.delay(1);
// 获取 B 元素
var rightButton = window.navigationBar().buttons()['Button'];
// 点击 B 元素
rightButton.tap();
运行后的效果是：A 元素被输入了122的字符——&然后 B 元素被点击——&APP 进入了一个页面
代码解读：
获取 A 元素：window.textFields()[0]，界面上只有一个textField，那么当然是textFields数组的第一个元素
获取 B 元素：window.navigationBar().buttons()['Button']，由于 B 元素是在navigationBar上，所以需要先获取navigationBar，再从buttons数组中获取 B 元素，通过 B 元素name属性的值Button(默认值)获取。
元素的name值也可以手动设置，比如设置 A 元素的name值为textField，注意：不要设置元素的可访问性（isAccessibilityElement）为NO
或者用代码设置
self.aView.accessibilityLabel = @"textField";
那么就可以通过下面这种方式获取
var textField = window.textFields()['textField'];
关于元素的可执行方法，比如tap()，可以查看苹果的。
以及元素数组包括：
1. buttons()
2. images()
3. scrollViews()
4. textFields()
5. webViews()
6. segmentedControls()
7. sliders()
8. staticTexts()
9. switches()
10. tabBar()
11. tableViews()
12. textViews()
13. toolbar()
14. toolbars()
15. secureTextFields() // 加密的UITextField
苹果另外也提供一个辅助检查功能工具，可以方便查看元素的信息打开设置（Settings）-- 通用（General）-- 辅助功能（Accessibility）-- 辅助功能检查器（Accessibility Inspector）
操作脚本录制
在④中创建一个新的脚本，在⑥中点击中间的红色按钮，代表开始录制用户操作并转换为JS代码，点击右侧的按钮，停止录制，点击左侧按钮，执行脚本。这时候你肯定在想，既然有这功能，还需要写什么脚本，真是这样吗？下面录制的一个同样的操作：点击 A 元素——&在键盘上输入112——&点击 B 元素
var target = UIATarget.localTarget();
target.frontMostApp().mainWindow().textFields()[0].textFields()[0].tap();
target.frontMostApp().keyboard().typeString("112");
target.frontMostApp().navigationBar().buttons()["Button"].tap();
这种方式生成的代码会有个问题，在各个操作之间都不会生成停顿代码，也就是target.delay();。如果对于那种夸页面的复杂操作，这种方式录制的脚本，在重新执行的时候有可能会报错。
举个例子：点击一个按钮后present到另一个页面，然后在另一个界面上点击上面的textfield，那么大概的脚本应该是这样：
var target = UIATarget.localTarget();
target.frontMostApp().mainWindow().buttons()[0].tap();
target.frontMostApp().mainWindow().textFields()[0].tap();
当执行到target.frontMostApp().mainWindow().textFields()[0].tap();这时候界面其实还处于前一个，那么获取textfield必然会有问题，所以如果遇到此类问题，不妨各个操作之间加入target.delay();试试。另外，缺少逻辑判断，比如当情况一点击这个按钮，情况二点击另一个。
所以想完全依靠这种方式，偷懒不用写脚本，基本上行不通。
UIATarget.localTarget().tap({x:100, y:200});
UIATarget.localTarget().doubleTap({x:100, y:200});
// 双指点击
UIATarget.localTarget().twoFingerTap({x:100, y:200});
UIATarget.localTarget().pinchOpenFromToForDuration({x:20, y:200},{x:300, y:200},2);
UIATarget.localTarget().pinchCloseFromToForDuration({x:20, y:200}, {x:300, y:200},2);
拖拽与划动
UIATarget.localTarget().pinchOpenFromToForDuration({x:20, y:200},{x:300, y:200},2);
UIATarget.localTarget().pinchCloseFromToForDuration({x:20, y:200}, {x:300, y:200},2);
UIALogger.logStart("xxx");
UIALogger.logFail("xxx");
UIALogger.logDebug("xxx");
命令行执行
使用命令行的原因是，Instruments工具跑测试实在太慢了，命令如下
instruments -t /Applications/Xcode.app/Contents/Applications/Instruments.app/Contents/PlugIns/AutomationInstrument.xrplugin/Contents/Resources/Automation.tracetemplate -w "iPhone 5s (8.3 Simulator)" /Users/xxxx/Library/Developer/CoreSimulator/Devices/A35F991E-425E-4F41-B76C-B7C176A06C36/data/Containers/Data/Application/324E3D2F-A0BC-4E96-97DF-97E791AB10A8/xxxx.app -e UIASCRIPT /Users/xxxx/Desktop/untitled.js -e UIARESULTSPATH /Users/xxxx/Desktop/tmp/
需要自行修改的部分
// 测试设备
-w "iPhone 5s (8.3 Simulator)"
// 项目目录，如果目录中没有xxxx.app也没关系
/Users/xxxx/Library/Developer/CoreSimulator/Devices/A35F991E-425E-4F41-B76C-B7C176A06C36/data/Containers/Data/Application/324E3D2F-A0BC-4E96-97DF-97E791AB10A8/xxxx.app
// 脚本目录
-e UIASCRIPT /Users/xxxx/Desktop/untitled.js
// 测试报告输出目录
-e UIARESULTSPATH /Users/xxxx/Desktop/tmp/
之所以说 UiAutomation 并没有想象中那么的完美的原因有下面几点：
JS脚本调试较为麻烦
UiAutomation 目前存在不少bug，比如手动设置accessibilityLabel无效、莫名其妙的报错，再跑一次又好了
不够完善，比如不能判断一个button是否可用（对应enabled属性），UIAlterView无法手动处理（网上提供的方法都无效），多份JS脚本，不能设置完成之后自动跑下一份
输出的测试报告比较简单，只有简单的log和截图，截图的规则也不太清楚（可能有提供截图的API）
另外推荐一个开源的测试库，以及。
注意：提交项目的时候若遇到Error itms-90035错误请尝试去掉库。
0 收藏&&|&&12
你可能感兴趣的文章
5 收藏，1.1k
感谢分享！！
感谢分享！！
分享到微博？
技术专栏，帮你记录编程中的点滴，提升你对技术的理解收藏感兴趣的文章，丰富自己的知识库
明天提醒我
我要该，理由是：点击阅读原文
移动端 App UI 自动化测试浅谈
日 发布，来源：
很多做测试的同学对UI自动化充满着向往，但又充满畏惧，经常不知道如何入手。一方面是因为技术薄弱，觉得自动化测试比较难，另一方面可能对自动化测试持怀疑态度。那到底什么是UI自动化测试，它能给我们带来什么样的价值呢？下面我们探讨下移动端的UI自动化方法。
什么是UI自动化？
首先，我们引用来自Monkey大神对的定义：UI自动化包括界面层面（控件，元素，位置，显示等的识别）以及功能交互层面（往往是通过代码或者测试框架来模拟真实用户的操作）
从个人的理解来看，UI自动化是通过工具或者脚本语言将测试过程模拟出来，并重复执行，用以验证功能是否正确的过程。
为什么要做UI自动化测试？
对于移动app而言，很多公司都采用敏捷开发的模式，因此测试也必须敏捷测试，每个迭代的周期非常短，经常要对原有功能进行回归测试，增加大量重复人力成本。引入UI自动化测试可以用来快速回归测试app原有功能，测试人员只需要关注新功能的测试。
移动端App的测试用例大部分是功能验证相关的用例，通过UI操作即可验证，这就为UI自动化提供了便利条件。
测试重复度高，执行效率低，通过UI自动化可以快速重复执行，达到提高测试效率的目的。
常用UI自动化测试工具
这几年，移动端技术发展非常迅速，测试手段也同样发展迅速，出现了大量用于对移动端app进行自动化测试的工具，下面简单列举下：
Monkey 是 Google 开发的UI/应用测试工具，也是命令行工具，主要针对压力测试。你可以在任意的模拟器示例或者设备上运行。Monkey 发送一个用户事件的 pseudo-random 流给系统，作为你开发应用的压力测试。
IOS UI Automation，基于IOS instrument。
MonkeyTalk 通过在App中加入client自动化为 iOS 和 Android 应用进行真实的，功能性交互测试。有成熟的集成开发环境，有API支持和持续集成解决方案，且方便二次开发，目前不开源，属于功能强大但没有被很好推广的测试框架。
Robolectric 是一款Android单元测试框架，使用 Android SDK jar，所以你可以使用测试驱动开发 Android 应用。
Robotium结合Android官方提供的测试框架达到对应用程序进行自动化的测试。另外，Robotium 4.0版本已经支持对WebView的操作。
uiautomator 测试框架提高用户界面（UI）的测试效率，通过自动创建功能 UI 测试示例，可以在一个或者多个设备上运行你的应用。
Selendroid 使用 Selenium 2 客户端 API 编写。可以在模拟器和实际设备上使用，也可以集成网格节点作为缩放和并行测试。
Appium是一个开源的、跨平台的自动化测试工具，适用于测试原生或混合型移动App，支持iOS、Android和FirefoxOS平台。
Calabash是一款适用于iOS和Android平台的跨平台应用测试框架，支持Cucumber，开源且免费，隶属于Xamarin公司。
主流跨平台UI自动化测试框架的对比分析
一个好的自动化测试框架，它应该是要能够支持跨平台的，目前市面上有三个主流的跨平台测试框架，这里简单比较分析三个框架的优缺点。
MonkeyTalk
支持的平台
Android、iOS、H5
Android、iOS、H5
Android、iOS、H5
Appium、Node、JDK、Android SDK、Selenium、Xcode
Calabash、Gem、Ruby、JDK、Android SDK、Xcode
MonkeyTalk、Android SDK、Xcode
支持的语言
Almost Any
MonkeyTalk、Java、Javascript
支持录制回放
通过扩展WebDriver API编写脚本模拟测试步骤，然后通过Server翻译后发送给对应的移动设备
使用Cucumber框架组织测试用例，通过Http和Json与测试app通信
通过嵌入在app中的client对用户操作进行录制回放
开源，社区活跃
行为描述语言，用例重用度高
录制回放，无需编码，环境易于搭建
大量编码，元素难以定位
环境复杂，UI难以定位
灵活性稍差，需要在App中安装Client
套用网上一位测试朋友的话，“自动化测试听起来很神秘，学起来很简单，用起来很麻烦”。UI自动化的优点很多，但要考虑适用场景，否则适得其反。同样，我们也要选好一个适合的自动化框架，这样才能提高效率。总而言之，想搞好自动化测试，还需要测试人员不断地提高测试理解力，分析能力和代码水平。
明天提醒我
我要该，理由是：
关闭理由：
删除理由：
忽略理由：
推广（招聘、广告、SEO 等）方面的内容
与已有问题重复（请编辑该提问指向已有相同问题）
答非所问，不符合答题要求
宜作评论而非答案
带有人身攻击、辱骂、仇恨等违反条款的内容
无法获得确切结果的问题
非开发直接相关的问题
非技术提问的讨论型问题
其他原因（请补充说明）几种常见的Android自动化测试框架及其应用
随着Android应用得越来越广，越来越多的公司推出了自己移动应用测试平台。例如，百度的MTC、东软易测云、Testin云测试平台……。由于自己所在项目组就是做终端测试工具的，故抽空了解了下几种常见的基于UI层面的自动化测试工具。趁晚上有空总结下，好记心不如烂笔头呀！
一&常见Android自动化测试框架及其应用
&&&&&&&&&目前，Android基于UI层面的自动化测试工具，都可以理解为是基于Android控件层面的，涉及Widgets和WebView两大类。其主流的测试方法主要有以下几种。一种是通过Android提供的各种服务，来获取当前窗口的视图信息。然后，在当前视图内查找目标控件，并根据该控件属性信息计算出该控件中心点的坐标，进而构造出一个Android
Input事件来实现对应用的自动化测试。其主要特点是：测试代码和被测应用各自运行在各自的进程内，相互独立。其代表有Uiautomator。另一种则是基于Instrumentation，通过把测试代码和应用代码，确切地说是测试APK和被测APK，运行在同一个进程中，通过Java反射机制，来获取当前窗口所有视图，并根据该视图查找到目标控件的属性信息，并计算出目标控件中心点坐标。然后，利用Instrument内部接口，实现点击操作。其代表有Robotium。
我们先来看下第一种。这类方法通常需要满足两个功能，一是能获取屏幕视图；二是能产生输入事件。这样，用户就可以通过屏幕视图查找到目标控件，进而计算出其中心点坐标，并由此产生一个输入事件来模拟用户操作。通常，这类框架还会提供一个截屏功能，方便用户对照。例如，分析定位问题等等。
目前，这类测试方法常见应用模式有以下几种：（1）、Hierachyview+monkey；（2）、uiautomator；（3）、accessibilityservice。（4）其他。先来说下第一种，Hierachyview+monkey的组合方式。
我们先来说下第一种，Hierachyview+monkey。其实现原理如下：
首先，hierahcyview通过socket与设备侧ViewServer建立连接，端口为4939。其次，通过命令“dump -1”获取控件属性信息。信息存入ViewNode中。第三，根据ViewNode信息，遍历控件树，查找到目标控件，并根据其bounds信息，计算出其中心点坐标。第四，根据计算出的坐标信息，发送一个点击该点的monkey命令给设备侧的monkey服务。除点击操作外，我们还可以通过Monkey服务进行输入、硬按键类操作。至此，对设备的一个自动化操作就完成了。这里需要说明的是，绝大部分商用手机ViewServer服务的开启都需要系统权限。故采用这种模式，手机一般需要root权限。另外，关于Hierachyview，CSDN上有一篇很好地介绍Hierachyview实现原理的文章，其连接地址如下：
。现摘录其部分内容，关于从设备侧ViewServer获取控件层次结构图的过程，以便大家更好地理解该模式。
HierachyViewerDirector.java（即Controller）通过DeviceBridge.java来和Android设备通信，而DeviceBridge.java具体是通过AndroidDebugBridage.java和DeviceConnection.java来和设备通信。备注：Hierachyview本身采用MVC模式。
AndroidDebugBridge.java :
AndroidDebugBridge.java是ADB API，位于ddmlib项目中。它实现了命令行版adb一样的功能，在HierarchyViewer中主要用到其连接设备，forward端口，启动ViewServer等操作。
DeviceConnection.java:&负责和ViewServer通信，向ViewServer发送命令并接受其返回的信息。从而获取Activity列表、控件层次结构图、截图等。
第二种应用模式Uiautomator。UiAutomator是Google仿照微软Uiautomation提供的一套自动化框架，基于Android
AccessilibilityService提供（注：Android
AccessilibilityService，是一个可访问服务，是一个为增强用户界面并帮助残疾用户的应用程序，或者用户可能无法完全与设备的交互。例如，用户在开车。那么用户就有可能需要添加额外的或者替代的用户反馈方式）。其应用方式有以下几种，一种是UiAutomatorView+monkey，另一种是直接调用UiAutomator
API。其中，第一种方法同hierachyview+monkey差不多。其区别是：UiAutomatorView通过ADB向设备侧发送一个dump命令，而不是建立一个socket，下载一个包含当前界面控件布局信息的xml文件。相比较hierachyview下载的内容而言，该文件小很多。因此，从效率上讲，这种方法比第一种应用模式快很多。第二种方法，则是直接调用UiAutomator框架对外提供的API，主要有UiDevice、UiSelector、UiObject等。其原理与第一种方式，即HierachyView+Monkey，差不多。其过程大致是：首先，UiAutomator测试框架通过Accessibilityservice，获取当前窗口的控件层次关系及属性信息，并查找到目标控件。若是点击事件，则计算出该控件的中心点坐标。其次，UiAutomator通过测试框架，注入用户事件（点击、输入类操作），从而实现模拟人的操作。UiAutomator对外提供UiAutomatorTestCase、UiDevice、UiSelector、UiObject、UiCollection、UiScrollable等类，其作用如下：
l&&UiAutomatorTestCase&：继承自Junit
TestCase&（Junit），对外提供setup、teardown等，以便初始化用例、清除环境等。
l&&UiDevice：此类主要包含了获取设备状态信息，和模拟用户至于设备的操作两类API。UiSelector，主要是通过一定查询方式，定位到所要操作的UI元素。
l&&UiObject：UiObject可代表页面的任意元素，它的各种属性定位通常通过UiSelector来完成。
l&&UiCollection：UiCollection一般与UiSelector连用，如它的构造函数也要求提供Uiselector:
UiCollection(UiSelector selector)。它的API较少，主要用以从Uiselector筛选出的元素集中挑出所要的元素:getChildByDescription(),
getChildByInstance(), getChildByText() ,以及统计元素集的个数getChildCount()。
l&&UiScrollable：UiScrollable&用来表示可以滑动的界面元素,其继承关系为UiObject
-& UiCollection -&UiScrollable。
但UiAutomator的实现方式与HierachyView+Monkey有很大不一样。以控件点击操作为例，其实现流程大致如下：
定义一个点击对象Object，该对象则通过UiSelector对象定位到具体的控件。而UiSelector则通过UiAutomatorBridge（它可看做是UiSelector与AccesibilityService之间的连接器），将查询内容（AccessibilityNodeInfo）和输入事件（AccessibilityEvent）传给AccessibilityService。实际业务过程比这复杂的多。这样，就实现了对某个控件的查找或点击操作。备注：AccessibilityEvent，所有可操纵的UI元素都定义为一个AccessibilityEeventt；AccessibilityNodeInfo指视窗中的组件树节点。&&&&
第三种则是accessibilityservice。先来介绍下Accessibilityserveice服务。前面已经讲过，它是一个Android的一个服务。若是用Accessibilityservice进行自动化，我们需要继承Accessibilityservice开发一个服务。这样，我们就可以依据这个服务获取当前界面的控件属性信息。其获取内容跟Uiautomator一样，都是AccessibilityNodeInfo。控件信息获取到后，若是要进行点击等操作，则可通过Monkey或其他方式，如Input等，来模拟点击操作。
上述几种Android测试方法中，UiAutomator比较正统，是Google正式推出的，也是应用范围最广的。另外几种方法，则见得不多，其中Hierachyview+monkey的方式，公司内部Ares就采用了。这类测试工具的一个好处就是可以跨应用。但不足之处也很多，速度慢、不支持WebView等（这种模式下，对WebView控制有限，无法注入Java
Script）。
接下来说下第二种框架，即Instrumentation，它是Android对外提供的一系列的测试方法的核心。Instumentation可看成一系列控制函数的集合，作用于系统和应用之间，类似于Windows中的Hook。在该测试框架下，主程序和测试程序需要运行在同一个进程中，见下图（图片来源CSDN，链接地址：）。
需要说明的是，在Android系统中，测试程序也是应用程序，我们可以将其看成一个没有UI的应用。
其实现过程大致如下：如图，InstrumentationTestRunner通过调用Instrumentation杀除应用程序的进程，再用Instrumentation重启该应用。这时，测试应用和被测应用就运行在同一进程下。测试应用怎么知道该测试哪个应用呢？嗯，这是通过在测试工程的mainfest文件中添加元素来实现的。当测试应用和被测应用运行在同一个进程里，它们之间就可以通过Instrumentation来进行消息交互，从而达到测试效果。当Instrumentation与某个程序交互时，其大致采用如下步骤：（资料来源：
http://blog.csdn.net/fireworkburn/article/details/）。
首先，启动时，初始化测试APK的配置文件AndroidManifest.xml文件中。该配置文件中标明了所使用的测试运行类、被测目标应用、包名等。然后，启动被测应用的Activity。同时，将测试ActivityThread做为一个引用进行初始化。此时，如果找不到目标应用则会报错。其次，执行测试脚本。测试时，测试工程中任何对目标应用进行的操作，都会用异步的方式，将消息体放在目标程序的MessageQueue中。这样，目标程序在查看到自己的MessageQueue中有内容时就会执行。&&&&&&
&&&&&&&&&基于Android
Instrumentiaon开发的测试工具有很多，其中最有名的恐怕要数Robotium了。目前，网络上很多移动应用测试平台，如百度移动应用测试平台MTC，都支持Robotium。
二&各类Android测试工具的TestCase继承关系
&&&&&&&&&Android提供了很多测试工具，如Monkey、Instrumentation、UiAutomator。其中，基于Android测试工具进行二次开发的测试工具也很多，如Robotium、Espresso。它们的继承关系下图：
UiAutomator
Testcase类继承自JUnit的TestCase类。而Robotium、Espresso则继承自activityInstrumentationTestCase2。从这个继承关系，我们也能理解为什么采用Robotium的方式，应用需要签名。而采用UiAutomator则不需要。其原因是：采用Robotium的方式，其测试代码本质上是一个APK。根据Android的安全机制，应用是需要签名的。
三&常见Android自动化框架优缺点关系
这里主要介绍下前面讲的几种测试工具的优缺点，包括HierachyView+Monkey、UiAutomator、Robotium。
Hierachyview+Monkey
UiAutomator + Monkey
是否需要签名
10s（网友测试数据）
4s（网友测试数据）
是否支持WebView
是否支持跨应用测试
支持该特性的Android API
是否支持控件ID
从上述数据来看，Android提供的测试工具各有优缺点，有的支持WebView测试，有的不支持。有的支持跨应用，有的不支持。因此，一个好的Android测试工具，更多地是兼容了上述几种测试方法。例如，Appium。
转自：http://bbs.c114.net/blog-2.html
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。App UI自动化测试在创业公司是否有意义？ - 知乎10被浏览495分享邀请回答0添加评论分享收藏感谢收起