前言

App自动化测试一直是小微团队很少会去涉足的领域，在互联网快速迭代这个大场景下，随着业务发展，回归压力逐渐增大。相信每次因为回归覆盖不足而导致线上事故，懊恼郁闷到要砸桌子的绝对不止我一个。

一般情况小微团队的测试包括回归测试都是人工进行的，一些偏离主流程却又比较关键的业务往往是人工回归测试容易遗漏的。人力有穷尽，这个时候自动化测试这个念头就从你的脑袋里冒出来了，然后就是去研究嘛。但可能最终也就止步于研究了。不谈自动化框架的搭建，种种细分的边界case,一个必然很繁琐的东西想一想就更繁琐了。如果你是App开发，本来业务开发上的人手就不是很充足，再去开发自动化脚本，有心无力!如果你是测试，每个迭代的业务需求测试就填满了你的排期，更何况承担的可不只是App测试任务。作为小微团队，自动化我们也想，但我们没有资源……

首先我们要明白App自动化测试并没有你预想中的那么强大，但如果你像我一样面临着回归测试痛点，它绝对可以满足你的需求。没有那么强大，所以也没有你预想中的那么复杂，同时它的参与者也绝不只应限制在Tester或Developer上，所以在资源上你可以有更灵活的调配。当然，自动化测试是一个长期的过程，它的未来，也绝不仅是回归……

最后我会为你安利一款偏冷的自动化测试工具：Calabash。并奉上Calabash入门教程博客和一点我的使用心得。介绍Calabash，是因为Calabash的特性在我个人看来更为适合资源紧缺的小微团队。

大话App自动化测试

仅代表个人观点，见识还浅，欢迎多多打脸。

现状

先说点大家都知道的。以Android为例，从2010年开始，Android开发环境以及其迅猛的态势发展到今天，几近趋于成熟，开发者的目光早已不在局限于这单一的开发平台，开始寻求Android，iOS在开发上的统一：ReactNactive,WEEX,H5……

开发环境已经成熟，但移动客户端的测试环境却有些滞后。这中间的几座大山是很多团队正在面对且驻足的：

1.App测试不像服务端测试通常只需对数据本身进行验证即可，App涉及到界面展示及交互，自动化识别难度大。 2.互联网企业一直都在追寻快速迭代，且App直接对接用户，App的界面与逻辑变更更是家常便饭，编写自动化测试脚本的稳定性很差，可能设计对界面的一次改动，之前与这个页面挂钩的所有脚本就都废掉了。 3.Android iOS 双平台,web页面。多平台的情况下想要依靠一套代码进行自动化测试几乎是不可能的。再考虑需要经常变更，你懂得。 4.比起人工来说，自动化测试可能需要为种种边界case编写很多的脚本。同比人工测试，可能需要的只是事先设计几个场景，其他的异常边界case通过测试中人为观察就好了。自动化测试成本倍增!

所以往往一个完善的移动自动化测试环境需要一个庞大的测试团队支撑，但一个庞大的测试团队只有大公司才能负担的起。移动的自动化测试，一直都在被中小型的创业公司所忽略。小型公司开发自测了事，中型公司依靠测试人员人工操作进行验证。

自动化测试真的对于小微团队紧闭大门吗?

Just do it

上面说的这些现状只能说是难题，也许现在讨论解决这些问题还早了些。我觉得你有些东西还没确定清楚，要不然先跟着我的思路走一走?等下面一些事情都想明白了，也许这些问题能避也就避过了，需要硬上的，也有足够心理准备了。

1.设定阶段计划试错

其实让小微团队面对自动化测试左右徘徊最大的一个问题就是：投入产出比! 很难去预估实行自动化测试后，在页面频繁变更与脚本的开发和维护之间，测试或开发人员会不会陷入泥潭。

但纸上谈兵永远也不会有结果，其他大公司的借鉴意义也不是很强，因为这涉及到团队、资源分配、业务变更频度、测试工具、脚本开发的解耦程度等等。不过自动化测试是一个必然的趋势，所以行动是最首要的!

你的团队目前到底适不适合，只有试了才知道。不妨先设定几个阶段，然后用第一阶段试错：

阶段1：抽出一个人一个迭代的资源完成主流程业务的自动化测试case，试运行两到三个迭代，并在这期间增加主流程异常case。利用这三个迭代来评估后续发展可行性! 阶段2-(阶段1成功度过)：如果你认为阶段1的状态还不错，那么在维护阶段1成果的基础上从剩余业务场景中按照业务关键程度、变更频率来选取一个新的业务，以一个人一个迭代一个业务的节奏编写自动化测试case!

阶段2-(阶段1过度失败)：当然，经过三个迭代的评估，随着异常case增多，同步维护难度越来越大，你可能认为实行自动化测试的成本过大，但也不要轻易放弃这三个迭代的成果。请先利用编程思维检查所有的测试脚本，是否有抽取相似代码，封装特定View操作，抽离与业务无关指令的可能。同时考虑利用全组资源就此维护这套主流程自动化case。直到将来资源充足或找到更好的替代方案后进行阶段3或重新阶段1。

阶段3：大概在5~8个迭代后，你成功撑过了阶段2，说明你的自动化测试环境已经步入正轨，那么这个时候可以按照团队资源情况适当加快自动化case覆盖率!

利用一人一个迭代的资源进行试错，相信是你可以接受的一个损失。当然，先不要急着做，你也许只是决定了要进行自动化测试，但还是要定一些详细的计划和一些思想、实际行动上的准备!

2.确定明确且简单的目标

有了大的计划，还要明确具体的需求，可选的需求大概有这么些：

1.黑盒测试还是白盒测试 虽然是UI自动化测试，但也可以分为黑盒或白盒，这个取决你想要的测试精密度，也就是在这个时候，可以初步确定要使用什么自动化测试工具。比如通常我们为了可以双平台会选择Appium这种可以跨平台的测试工具，但假如你有很高的测试要求，以Android为例，建议你使用Android官方推荐的测试框架：Espresso，直接在Android工程项目中写Test。 这样说出来好像谁都明白，但如果你不能在前期就明确你的需求，可能会在后期带来很大的困扰!选择Appium，因为是黑盒，遇到某些特殊的场景或需求，导致个别case无法测试。或者选择了Espresso，但后来发现其实并没有那么精密的测试需求，导致后期无法跨平台或者认为Espresso编写成本过高，还很难移交给测试团队。

2.前端UI还是整体业务 举个例子，抢单并且进行配送这个场景。发现一个订单并点击抢单，然后进行取餐，最后完成配送这一套只能用肉眼观察到的UI层操作，我们暂定为这是前端UI逻辑。但在这一系列操作背后订单状态流转引起其他数据变动，比如：钱包数据变更，活动奖励数据变更，欺诈单判定等等这个范围，就属于整体业务范畴了。 而我们需要现在确定的，就是你想要达到的测试期望是UI测试，还是整体业务测试。这直接决定了你测试脚本的复杂度。而我的建议是仅测UI逻辑，也是我想让你降低期望一个点。

先确定一个明确且简单的目标，然后一头扎进去。如果想的多了，困难也就多了，最后可能也就只是想想了，这就是下面紧接着要说的点：降低期望!

3.降低期望

在人工(对着手机点点点)测试的环境下，我们通常都是通过操作App进行各种case验证，只要操作app验证通过了那基本可以确定前后端没什么问题了。但这个前提是人工验证是人脑加肉眼，它会有更准确的主观判断。 涉及到前后端交互会增加极大的复杂性，你的测试case不会无限多无限精细，但作为人脑你可以在有限的case执行中发现更多不符合常理的bug：文字不合理的折行，不准确的数值显示，按钮颜色不对，Toast展示数量有误等等等。自动化测试会死板的跟着你写的脚本走，你能保证你的case覆盖到了所有了吗?

这也是谈到自动化测试，好多人都会抛出的一个疑问，那么多异常case怎么写啊，想想都累，考虑一下投入产出比要不还是人工测试吧。

首先要明确的一点，前后端自动化测试一定要分开，一套解决不了问题，这样在前端测试中可以忽略很多的case。 另外自动化测试是一个与项目成长一样的长期过程，自动化完全代替人工依然还需要走一段时间，你不要想着一步到位。 依然还是会有很多的case要写对吧?资源不够我们可以先跑通主流程再说，跑通主流程也就意味着脚本依赖(环境搭建，view定位)已经较为成熟了，其他异常case脚本对着主流程脚本修改即可，这个我们慢慢来嘛，而且这个时候你就可以放开给别的开发或测试让他们照猫画虎了。这也就是我们上面说的阶段1。

如果这些问题不能想通，你会发现在App自动化测试条件有限的情况下，并不能实现你想要的结果，从而迫于压力而放弃了。说服自己降低期望!

• 降低期望，先以回归为目标
• 降低期望，前后端自动化测试都要有，一套解决不了问题
• 降低期望，客户端自动化测试限制依然很多，人工测试验证不能全部丢下
• 降低期望，一口吃不成个胖子，自动化测试也是需要慢慢迭代完善的，先跑通再关心验证异常case。快速迭代，逐步完善

4.术业有专攻

也许你的团队里是开发或者测试中的某一方无法承受压力，从而开始探索App自动化测试。 开发去做自动化测试的优点在于因为有更丰富的开发经验，测试环境的搭建更为熟练，且因为是自己写的代码，会更了解风险点在哪里，能写出有针对性的case。测试去做自动化测试的优点在于发现更多的边界场景，写出更全面的测试case。

在自动化测试上，开发和测试各具不同的优势，但同时这也是对方的劣势。

测试case一定要越全面越好，而且自动化测试本身就是一个工程项目，在写脚本时，如果更多的考虑一些编程思想，合理的耦合和解耦，将会让之后的脚本编写更便捷。 所以，非常不建议自动化测试完全单独交给测试人员或开发人员来负责，最好是一种紧密合作的关系。同时也是应对资源不足的一个解决之道。虽是测试，但有开发的加入，会让测试工程朝着更优的方向发展。

5.一个巴掌拍不响

首先再次明确我的一个观点：在没有足够的资源的情况下，移动客户端自动化测试，主要针对的应该是回归测试。

自动化测试相比起人工测试，是非常死板的，那么就需要非常“死板”的数据支持.如果是App开发(就像我)去做自动化测试这件事，难道所有数据我都要mock一遍吗?虽说前后端自动化应该分开，前面也说了应该只关心前端逻辑。但一定还是要在真实的服务环境(测试环境，非生产环境)进行测试。 mock数据过于死板，很多case可能就无法验证了，比如注册场景，要验证注册过的账号无法再注册时的异常提示，mock数据显然较难兼顾正常注册和异常注册两种。而且在真实环境中测试，万一测出来一个后端bug不挺好么。 而且，手机淘宝这样完全2C的应用直接在生产环境测试好像没什么太大问题，但像蜂鸟配送这样半2C的应用来说就比较尴尬，直接去抢线上单明显不可能，那么在测试环境这个订单谁来发怎么发呢?

所以这个时候你就不能自己单干了，去找测试同学，看能不能搞一个配合自动化测试的测试环境，拿抢单来说，我希望这个环境上永远有好多单让我抢。我就是抢单的app，没单我还玩什么。

如果测试同学搞不定，那么就去拉后端的同学啦，我相信为了项目越来越好，他们是不会拒绝你的。

自动化测试，不仅是自动化测试工具就够了，同样还需要测试环境的支持。

小结

其实说了这么多，就是想要你降低期望，并付诸行动。 App的自动化识别和多平台自然会有大批的自动化工具帮你实现，而学会降低期望的同时也会降低脚本开发和维护的难度。