[分享] 自动化测试与持续集成方案-- UI 检查

对于自动化测试中，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     |

2. 有人跟我说，多语言存在问题。

这个我要好好研究一下。