工作这么久，已近不惑之年，将这些年的一些经验教训沉淀下，给后来的小伙伴们分享下，希望能对大家有用。这篇文章作为开山之作吧，感谢云加社区的平台提供一席之地。

目标 – 要干啥

手机作为一个工具已经成为大家日常生活和工作的重要组成部分，APP的使用也越来越普及，在生活和工作中扮演着越来越重要的部分，其产品的研发也越发火热。有研发就有测试，有测试就想要自动化，APP的自动化工具现在也是百花齐放，不管大小公司大小产品，没做自动化感觉差点啥。本文简单介绍下从无到有做自动化，我经历的一些产品实践中的想法和经验。

自动化能用来干啥？

（1）直接测试新功能？有钱有人有时间未必不可行啊！测试驱动开发，需求分析后，自动化测试和开发同步进行，或者说先于开发进行，这是敏捷开发的一种重要实践。这个实践很好很好哈，将缺陷消灭在编程阶段，但是，好的东西它贵啊，真贵啊，要有人有能力，有时间有资源去实现。

（2）自动化不只可以用来做自动化测试，还可以做自动化环境部署，自动化数据准备，等等。根据项目的需求，还有项目的技术能力，有多少人，干多少事。

（3）回归测试自动化，这个也是大家说的最多的自动化，多用于产品的回归测试中。当产品生命周期比较长，功能点众多，后期产品逐步增加新功能，或者是修改老功能，已有功能的回归测试会越来越多，产品稳定的情况下，用自动化实现产品已有功能和重点缺陷的回归测试，是个不错的买卖，性价比比较高。

（4）稳定的输出结果，替代人工测试。测试人员写自动化就是为了让自己以后失业？？呵呵，开玩笑，只要产品有新功能，就需要不断维护自动化，产品变了自动化也相应的需要去变化，我们就有了新工作要去做呀。但是不可否认的是，有了自动化后，后期回归测试需要的人力资源会愈来愈少，而且，自动化测试执行稳定，同样的用例和数据跑出来的结果也是一样的，不会出现测试同样的功能张三没发现缺陷李四发现了缺陷。

说了这么多，都没说到APP自动化。自动化的思路和原则都是一样的，区别是不同的产品和平台，使用的技术和注意的侧重点稍有不同。本文从APP自动化的角度，介绍下自动化的一些实践和方案。

方案 – 啥方法

我们要实现的APP自动化方案，简单来说，包括了自动化打包，自动化部署，和自动化测试这几个部分。如果有条件，还可以加上精准测试的覆盖率分析等实践。这些步骤可以通过持续集成工具，如Jenkins，集合中一起，根据项目需求和情况部署多种方式使用。实现这个方案可能用到的工具有：Appium，Jenkins，Android Studio，python，shell，git，svn，等。

自动化打包是指结合开发的源代码库，通过脚本或者工具拉取最新或者特定分支的源代码，将其编辑打包，生成部署包。这里注意测试包和生产包的区别，一般使用不同的脚本，或者配置不同的变量来控制。此处建议使用各自独立的脚本，避免手工设置或输入一些参数造成的失误。如果项目是基于maven的，依赖第三方的库要去下载，这个打包可能会是一件比较耗时的事情。

自动化部署是指将部署包安装到指定的环境里，启动服务以供使用。这里一般会涉及到文件的解压，拷贝，编辑，环境变量的设置，服务的启动，对多个服务器的访问，等等。一般使用脚本或者部署工具实现。有些项目也会将自动化打包和自动化部署集成到一起实现。

自动化测试指的就是测试用例的自动化。拿到产品后一般的过程是，先做测试用例设计，挑出适合自动化的用例来，做个用例评审，然后再去做自动化。这样保证好钢用在刀刃上，性价比最高。啥样的用例适合自动化呢，一个是业务决定的，一个是技术决定的？核心的业务，容易实现的业务，现有的技术水平能实现的。

选好了自动化用例后，后边就是它们的设计和实现，这个时候一般考虑要到以下几个方面。

（1）数据和用例的分离。自动化用例不是一次性的产品，写出来后被长期反复执行，才能实现它的最大价值，这就涉及到后期自动化用例维护的成本。所以我们写自动化用例的时候，就要慎重考虑到这个用例是否易于维护。数据和用例的分离是最基础的，可以提高其执行效率，因为实际测试时大都是同样的场景下要测试不同类型的数据，数据和步骤分离后就可以复用步骤，一旦发生变化时，不用到处修改。

（2）页面和操作的分离。页面的变化频率一般高于操作步骤，也就是说，页面上元素的位置可能经常变化，但是其功能时不变的，而且多个用例需要操作同样的页面元素。实现了页面和操作分离后，只需要维护一处的元素路径信息，操作中都是对它的引用而不用修改，降低其维护成本。

（3）操作和用例的分离。用例包含业务逻辑的验证点，而操作是实现业务逻辑的步骤。一个操作可能会被多个用例调用，比如说，若干个测试用例中都有创建订单操作，将此操作分离出来后，一旦创建订单的步骤发生了修改，只需要此操作的实现，用例中的步骤都是对他的引用而不用修改。

（4）执行的稳定性。自动化测试，尤其是页面自动话，还有涉及到多个产品交互的自动化，其运行稳定性是个大问题。也就是说，同样的自动化用例，这次执行通过了，下次因为网络延迟，或者其他产品响应慢，页面刷不出来，结果没有及时返回，等情况，可能就执行失败了。这个时候就要采取各种手段，来保证自动化用例执行的稳定性。一般会带来额外的开销，如反复调用系统服务，延长等待时间，等等。

（5）执行的效率。为了保证稳定性，有时候就会牺牲自动化执行的效率。比如说本来各种情况完美的情况下1s就能执行完一条用例，但是遇上网络延迟，其他产品返回结果慢等情况，可能90s才能执行成功。为了保证稳定性，加上了90s的等待时间，用例就从1s延长到了90s。此时我们也可以采取一些手段来减少等待时间，比如说轮询机制，没接到返回结果之前，多次调用查询结果方法，直到完成为止，而不是所有情况下都等待90s。

如果产品的依赖环境特别复杂，推荐一个利器，那就是挡板服务。挡板竖起来，后边服务就不用等待了，可以直接模拟各种返回结果，关注于本产品的业务逻辑即可，大大提高测试执行稳定性啊。但是，此处有好几个但是，请注意！

（1）一个是挡板测试只是模拟其他系统的返回，是否能完整模拟到真实情况，这个要打一定折扣。此处风险极高，请特别注意。

（2）一个是挡板服务的开发需要投入一定成本，尤其是复杂系统的数据模拟，各种情况各种数据不亚于开发一个后台系统，性价比需要考虑下。

（3）一个是有些服务很难或者无法使用挡板服务实现，例如没有对外暴露的接口调用，或者授权方案无法模拟，等。

（4）挡板服务也是一个独立的系统，挡板服务本身的问题也会给测试带来一定风险。

覆盖率分析可以用来检查自动化测试，或者是手工测试，的执行效果。它会启动一个独立的服务，监控代码哪些做测试时被执行，最后生成所有测试执行过的代码覆盖率报告，可以从包覆盖，文件覆盖，代码行覆盖，分支覆盖等维度检查测试执行的效果。

实践 – 怎么干

不要提前优化！一步一步来，根据现有的人力和技术实现能自动化的部分。也就是说，基于最基本的原则，先把自动化跑起来，能提高一点效率的同时，也能激发大家的兴趣，满足团队的成就感。罗马不是一天建成的，胖子也不是一口就吃起来的。先把眼前的事情做好，后续根据需要慢慢优化和增加新内容。

假设我们要实现自动化的APP产品所在产品线如下图所示，我们的自动化实现怎么做呢？

这么复杂的产品线，依赖于这么多的产品，妥妥的稳定性很不好做啊。咋办勒？凉拌啊～～哈哈哈，一步一步来。如前文所说，先做自动化打包，再做自动化部署，然后再做自动化测试，最后有条件再上挡板测试，覆盖率分析，等等。整体的测试方案实现内容如下图所示：

以上每个步骤的实践可以分批逐步实现，从上到下逐步优化。每个部分的实现如果展开来讲，内容都太多了，本篇文章难以展开讨论，此处就给出各个部分推荐使用的一些工具。

自动化打包：

（1）首推Jenkins，本身就提供了界面化的连接访问各种版本控制工具的连接方式，如git，svn等等，可以比较方便的配置连接代码库，下载地址代码，然后配合Jenkins的部署命令和各依赖关系设置，环境设置等功能，可以方便的实现自动化打包。当然，前期需要使用Android Studio配置相应的环境，下载依赖包啥的。

（2）手写shell和bash脚本，甚至Java等程序。如果不想专门搭建一个Jenkins服务器实现打包的功能，可以自己手写shell和bash脚本实现打包，甚至可以使用Java，python等语言编码实现，看各位更熟悉那种技术了。

（3）其他持续集成工具。其他业界也有很多打包工具可以使用，如Ant，等。

自动化部署：

（1）依然首推Jenkins。可以通过页面操作，方便集成各种工具。

（2）写程序或者脚本实现。黑猫白猫抓到耗子就是好猫，大家用最方便的就行。

（3）其他部署工具。

自动化测试：

（1）Appium：脚本语言编写，成熟稳定的自动化框架，容易上手。

（2）夜神模拟器：模拟手机操作，还可以查看页面元素路径，方便实现抓取页面元素。

（3）各种脚本语言：辅助实现自动化步骤中的各种操作。

（4）其他自动化框架。

挡板测试：

（1）Flask：轻便，容易上手，试错成本低，使用python实现。

（2）其他开源挡板程序，如moco,Mockito，EasyMock，jMock，JMockit，等等。

覆盖率分析：

（1）NYC：分析JS代码的覆盖率，istanbul的升级版。

（2）其他覆盖率分析工具。

使用 – 咋用呢

自动化用例编写完成后，如何能最大程度发挥它的价值呢？建议是尽可能的提高其有效执行次数。很多团队自动化用例写出来后，因为维护成本高、执行时间长等各种原因，很少执行自动化，或者有些用例就不再执行。从某些角度上来说，不再执行的用例就时死的用例，不再有价值了。这就造成了很大浪费。为了减少这些浪费，建议中初期写用例的时候，不要求多。稳中求进，写出来的用例后期要维护和使用起来，才能发挥其最大的价值。

如果原有自动化用例维护成本高，建议在合适的时机，对自动化进行重构，梳理出一份可以维护和使用的用例。可以一步步做，但是请不让代码死掉，失去他们存在的意义。

如果自动化用例全部执行时间长，建议单独搭建一个跑自动化的服务器，每个版本主要功能稳定后尽早启动全量回归测试，或者是利用周末和晚上的时间，大量执行全量的自动化。

自动化执行可以根据需要分批执行不同的代码，比如版本提交后，可以执行少量的版本验收用例，十分钟内能跑完的。大功能体测后，可以跑一边主流程用例，看看其对主要流程的影响。特定场景下，比如说单独需要某个模块的测试情况，可以只执行单独模块的用例。这些都需要做自动化测试设计时，对用例进行规划，编写自动化用例的时候，将其添加到相应的测试集合中。

结束语

写到一半的时候，我就发现这个题目太大啦！不是一篇文章能讲清楚的事情。各处的细节说的不清楚的地方，后续我再补充详细说吧。以上就是这次要分享的内容了，希望对大家有一二参考，提供一些帮助。

感谢刚参加的技术创组101训练营提供的指导，让我迈出了第一步。后续继续努力！