移动端 UI 自动化测试调研
前言
目前打算开展自动化测试，现阶段主要针对 android，现在想要多做一些功课，避免开展后各种乱，当然坑是很难一步绕过，因为之前用 Robotium 写过一次自动化，由于界面重新设计被搁置了，当时上来就写，最后感觉各种乱，可复用的东西也很少，维护起来也不方便。
自动化的意义
真正意义上的减少或取代人工，我也知道完全取代人工只是一种理想状态，如果自动化对手功测试毫无帮助那便是无意义的。
如何开展
首先我打算整理出一份自动化覆盖列表，方便记录和理清哪些模块是可以实现自动化。
调研
调研行业流行的自动化测试方法\流程\测试工具
大家都在用什么工具做移动端自动化测试，具体方法流程是怎么样的？
自动化工具比较：
- Robotium： 优点： 缺点： 适用场景： 2.Appium： 优点： 缺点： 适用场景：
3.其它工具：
这部分我会自己调研后补充，如有切实体会的欢迎回贴
头脑风暴及求助
- 测试数据与脚本分离
我之前只是单独建了一个类存放所有的测试数据，对每个数据按一定规则命名，不知道大家在用什么样的方式管理测试数据。代码如下
public class TestData
{
/****************test_001_User start********************/
public static final String userid_case_001 = "";
public static final String userid_case_002 = "123456";
public static final String userid_case_003 ="abc123456";
public static final String userid_case_004 ="1234abc";
public static final String userid_case_005 ="23761210";
public static final String userid_case_006 = "23742839";
public static final String userid_case_007 = "中文";
public static final String userid_case_008 = "English";
public static final String userid_case_009 = "한국어";
public static final String userid_case_010 = "こんにちは";
}
求助
- 我想知道大家都是用的什么方式对脚本和数据进行的分离，最好说具体些
- 关于命名规则，什么样的命名方式方便日后维护和阅读，包括类名，方法名，数据名等... 或者吐槽一下遇到的坑之类的。
PS:上边代码片断只是一个示例
待续
还没想好怎么表达
总之，我想写一套可读性强，复用率高，方便维护的自动化脚本（哈哈~~~，可能每个人都是这么想）前期准备想做的深入一些，再开展。
你的理想状态是出一套自动化工具 针对你们产品的，而不是一套脚本
你这个问题我的理解其实就是脚本架构设计和编码规范。其实这和开发已经是一个概念的东西了（都是编程序嘛），所以你也可以请教一下你们开发（最好是架构师这个级别的，他们走过很多坑，所以给出的方案一般可行性比较好）
我在这里按照我所知道的回答一下你的两个问题吧：
我想知道大家都是用的什么方式对脚本和数据进行的分离，最好说具体些
我们目前没有做很明确的分离，只是把跨用例的共用的数据放到一些 global 变量中共用。因为我们的项目基本上没多少数据输入的场景。对于登录这类需要用很多种数据来尝试的，我们在登录这个脚本里面单独写（因为其他脚本也用不上，分离出来意义不大）
关于命名规则，什么样的命名方式方便日后维护和阅读，包括类名，方法名，数据名等...
命名规则这个还真说不准，看你的脚本架构是按什么来确定这是一个类/方法的。如果是按照模块，那么类名自然是模块名称，方法名就是用例名称。用例名称能表达这个用例的测试点就可以了。如果你说的是调用的方法的封装，我们采用的是类似 robotframework 的命名方式：带有自校验的用
xxx should be，进行元素操作的：click element，get element text，get element attribute。
PS：对于数据，正常情况下我不会采用你上面这种用序号结尾的命名方式，因为从名字上完全不知道这个数据是干嘛的，每次使用数据都要去声明文件里查，而且后面改数据也不知道这个数据是干吗用的，应该改哪个数据。
如果是同一用途的数据，我会用个 array 封装起来。如果是不同用途的，我会根据数据的用途来命名。如果数据实在太复杂，我会用表格来保存数据（其实表格保存是最清晰的和容易修改的）。
自动化的意义：把重复的手工操作人力释放出来，缩短版本测试周期
如何开展：可以按产品线来分，以点带线再带面。如：每个产品线出一个接口人，你前期带这些接口人，用你的开发好的工具编写脚本、定制自动化方案、实施
脚本数据分离：尽量降低工具入门门槛，通过 NoCoding 方式来编写 WEB、Mobile、Service、DB 等等自动化测试脚本编写，如：自动化框架层面，设计数据池、控件 Map、数据驱动池等等
这个问题太大了，个人经验供参考：
1.首先要看老板或者领导愿意投入多大的意愿去干这么一件事情。如果领导只是说说建议你谨慎，因为中间他可能催你，可能觉得你进展慢，你遇到困难时，可能获得的支持有限。
2.建议测试对象必须是稍微稳定点的产品，如果产品的稳定性都没法保证，建议你缓缓，因为 PM 肯定是向着开发而不是向着你，这样会很痛苦。
3.流程方法这些大部分这里只能提个皮毛，用例和最后的实践很多涉及信息安全啥的，不方便提。自动化测试用例可以参考 SHIXUE33 美女前段时间发的帖子，大部分内容都包括，可以参考这个来做。论坛获取到的信息一般都是技术层面上的和零散的一些信息，如果有可能还是尽量从内部挖掘一些流程上整体上资源。~
4.UI 自动化只是最基本的，安全性能等等，总之还是要贴近自己的应用，知道哪些能做，哪些不能做，哪些做起来很麻烦。没有什么理想中一蹴而就的东西，就是填的坑多了，也就那样了。~
共勉之~
#2 楼 @chenhengjie123 我最初以序号命名是为了和测试方法 testcase 一一对应，但后期也意识到这个问题了，虽然按序号命名看起来很整洁，但因为多记不住，每次都会去看一下这个数据的值是什么，感觉 userid_case_001 没有 userid_null 看的直接简明。
你说的表格保存数据，是存到文件，最后去读文件吗？
#4 楼 @yangchengtest 你说的的确是实实在在存在的问题，可能我发贴的目的是边自己梳理，边收集一些自己考虑不的到的问题，共勉之~
#3 楼 @cpfeng0124 我目前只是个人调研阶段，应该不会给我调配那么多人来，可能大家都知道自动化的确很重要，但是小公司重视度不会像手动测试那么紧，NOCoding 的确是很好的想法，如果能降低门槛推广起来的确很容易
#2 楼 @chenhengjie123 非常谢谢，收集到很多信息，听君一席话，胜读十年书
@emily Pageobject 适合你们的业务抽离
要是做 CI 的话 你不封装业务后期是来不及修改的
我作为资深自动化架构师，给几个最基础编写中建议：
1、appium：android 千万不要用 appium，坑，等半年后看反馈用；ios 可以用 appium；
2、robotium：android 建议用 robotium，深入点，搭建服务器和测试客户端模式；
3、重要核心：UI 用例最重要的不是覆盖率，是准确率，误报率超 5% 基本就没用；
4、校验点：每走一步都要踏实，每写一个用例都要投入，要写完善，准确的校验点要正确且通用；
5、原子化：每个用例都要原子化，可独立运行校验；
其他的自动化整体架构方面，我看到你有想法，但是没计划，没目标。
@pighero001 资深。。 麻烦讲下您遇到的坑
@pighero001 同问，能否具体说说为什么 ios 推荐 appium，而 android 不推荐？
吃不到葡萄说葡萄酸
#17 楼 @huangyaoshiauto
#18 楼 @nancy2896
#19 楼 @doria
葡萄酸不酸，要看你怎么吃了，我是直接吃的所以觉得酸，但是如果你投入大点，放一罐糖腌一下，也是甜的。
投入再大一点，把 appium 源码改改，也就没这一说了。
目前不推荐，谁用谁知道，我要把我的那些坑说了，你们肯定又有理由，这个问题可以这样这样解决啊。但是要想下，有没有必要。我用 robotium 不需要修改他的源码即可使用，用 appium 需要改源码，你自己衡量。（PS.我用的时候，是两个月之前的 appium-android，不知道现在这些问题改过没）
#20 楼 @pighero001 那 uiautomator 是不是要比 Robotium 好，Robotium 不能能跨应用就好受影响的
关于 1、appium 你说的坑大致可以描述一下吗，或者有没有一个和 robotium 的优缺点对比，我用过 robotium 正打算试一下 appium
关于 3、我也感觉准确率要比覆盖率更有用。
关于 4、校验点通用是什么意思？能说详细一些吗
关于 5、原子化的确很重要，但有一些功能之前是有相互依赖的，很难做到独立运行校验，比如回复帖子需要先登录
其他的自动化整体架构方面的确是没有计划和目标，你有什么好的建议吗？