对于自动化测试中，UI 自动化测试估计是最有争议的，让人又爱又恨。
UI 自动化做回归测试，可以省下很多人力。如果版本一直不稳定，投入跟产出不成比例的。
时机
一般是要版本稳定，界面改动不大。如果迭代版本一个接一个，界面改动大，这样就无法大规模投入 UI 自动化。因为你的维护成本大。也许你脚本还没改好，下一个版本又来了。
有些测试会说，还没有我手动快，没我手动发现的 bug 多。做 UI 自动化就是图个放心，测试的时候只测增量，原有的功能，用 UI 自动化去检测，看是否有改动，原有功能是否是好的。如果你指望它能发现很多 bug , 那你还不如手工。
产品
如果项目周期很短的产品，那你就别想了。可能你还没弄完，项目就结束了，英雄无用武之地。
迭代快，界面变化大的也别考虑了。
工具
现在能跨平台的工具不多。如果只写和维护一套脚本，既能跑在 Android 上，又能跑在 IOS 上，那会省时省力很多。
14年的时候用 Appium, 那时候 Appium 还很不成熟，不支持中文，然后我们的产品很多元素无法定位, 最终放弃了。
然后尝试用 calabash. 用这个工具主要看中它基本跨平台，然后简单，一般的测试很容易上手。
Calabash 学习经验小结 http://testerhome.com/topics/1173
Calabash Android 简介 http://testerhome.com/topics/606
超详细的 calabash-iOS 安装步骤 http://testerhome.com/topics/2129
Calabash 模拟多手机同步测试 http://testerhome.com/topics/1520
虽然检测的点很粗线条，但也能实现 UI 自动化的检测。
规模
UI 自动化要达到多大的覆盖率，跟手工用例的比率，这个要根据公司人员的配置，产品的特点，以及对质量的重视程度来决定的。
问题
1. 现在弄 Scenario Outline 的时候还没有弄通过
类似这样
Scenario Outline: Caculate Expressions
Given the table input <Input> When the calculator is run Then the output from table should be <Output> Examples: | Input | Output | | "3+5" | 8 | | "25-4" | 21 | | "10/2" | 5 | | "25+5*3"| 40 | | "4-5" | -1 |