5分钟带你玩转App自动化测试

前言

这篇博客，我会站在小微团队的角度，介绍一下我对App自动化测试的一些看法。在帮助你降低对App自动化测试的期望的同时说服你开始实践App自动化测试。

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覆盖率！

利用一人一个迭代的资源进行试