自动化测试主要分为三层：UI层、接口层、单元层。

移动端、web端通常所说的自动化测试是指UI层测试，基本原理就是：基于页面元素的识别和定位来模拟用户行为，首先识别到某个元素，比如一个按钮，然后定义一个动作，比如点击，这样就通过代码模拟完成了一次按钮的点击，代替了人工去点击。如果后期再加入数据驱动和Page Object思想就基本可以形成一个UI层自动化测试框架了。

作者：黄小明_4310
链接：https://www.jianshu.com/p/4e2f19c7b8a8
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

1.将电脑和路由器分别上电，将网线一段接路由器console口，一段连接电脑网口

2.点击电脑的左下角“开始”按钮---程序---附件---通讯---超级终端，打开超级终端后，随便起个名字，选个图标确定即可，这样电脑就会与路由器相连，当出现如图的画面时，连接成功。

3.下面开始配置路由器，首先配置路由器名称如"R1",enable+回车---conf空格t+回车---hostname空格R1

配置路由器端口的基本参数ip地址，端口速率，单双工，以fastethernet0/0为例，enable+回车---conf空格t+回车---interface空格fa0/0---ip空格address空格192.168.10.1空格255.255.255.0+回车---no空格shutdown---speed空格auto（这里可以选10,100，auto）---duplex空格auto（这里可以选half，full，auto）

4.配置进入特权模式密码以及telnet，enable+回车---conf空格t+回车---enable空格password空格cisco+回车---line空格console空格0+回车---login+回车---line空格vty空格0空格4+回车---password空格telvent+回车---login+回车

5.将电脑的网口与刚配置好的路由器端口连接，将电脑ip改在和路由器一个网段上，打开cmd---telnet空格192.168.10.1就可以同样对路由器配置了。

在开始设计自动化测试框架之前，需要考虑下：

使用该框架写出来的自动化测试案例，需要给开发，手动测试，可能还有客户查看，所以写的测试案例需要尽量的清晰明了，不要有太多复杂逻辑，及比较好的可读性。

使用这个框架做自动化的人，不会有太深的编程能力，所以要提供足够好的，最好是傻瓜化的测试点验证方法，及很好的异常容错处理能力。

测试框架最好是app测试，网页测试，接口测试，统统都能支持。

testbird - 手游和app自动化测试平台

1：稳定性测试利器——Monkey

要想发布一个新版本，得先通过稳定性测试。理想情况是找个上幼儿园的弟弟妹妹，打开应用把手机交给他，让他胡乱的玩，看你的程序能不能接受这样的折腾。但是我们身边不可能都有正太和萝莉，也不能保证他们拿到手机后不是测试软件的健壮性，反而测试你的手机经不经摔，这与我们的期望差太远了…
Google公司考虑到我们的需要，开发出了Monkey这个工具。但在很多人的印象中，Monkey测试就是让设备随机的乱点，事件都是随机产生的，不带任何人的主观性。很少有人知道，其实Monkey也可以用来做简单的自动化测试工作。

2：Monkey之子——MonkeyRunner

Monkey虽然能实现部分的自动化测试任务，但本身有很多的局限性，例如不支持截屏，点击事件是基于坐标的，不支持录制回放等。我们在实际应用中，尽量关注利用好Monkey测试的优势。若平时的工作中遇到Monkey工具无法满足的，这里给大家推荐另一款工具MonkeyRunner。
同样先简单的介绍下MonkeyRunner的API，这里重点介绍能够实现上文Monkey脚本的API，其余的API感兴趣的小伙伴可以自行查阅。
(1) 等待设备连接：waitForConnection()
(2) 安装apk应用：installPackage(String path)
(3) 启动应用：startActivity(String packageName+activityName)
(4) 点击事件：touch(int xPos, int yPos, dictionary type)
(5) 输入事件：type(String text)
(6) 等待：slee p(int second)
(7) 截图：takeSnapshot()
(8) 发送键值：press(String name, dictionary type)

①：想实现自动化，第一步先安装python然后第二步安装selenium,

第三步安装JDK,然后J配置好JDK环境变量

JAVA_HOME    C:\Program Files\Java\jdk1.7.0_13

CLASSPATH   %JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar
Path：     %JAVA_HOME%\bin;%JAVA_HOME%\jre\bin;

第四步：到Node.js网站下载Node安装

下载好后，傻瓜式默认安装，安装完后，输入：npm version ，出现以下信息，表示安装成功。

第五步：安装appium，下载好之后，傻瓜式的安装即可，你也不一定要跟我一样选择1.12.1，你可以选择其他版本的

第五步：安装Android SDK 环境安装，

环境变量配置

变量名：ANDROID_HOME
变量值：E:\ruanjian\android\adt\sdk （根据你自己磁盘来给路径）
变量名：PATH
变量值：;%ANDROID_HOME%\platform-tools;%ANDROID_HOME%\tools;

第六步：安装Appium-Python-Client  

pip install Appium-Python-Client

表示成功

第七步：然后你的adb命令就可以用啦

第八步：要想adb运行成功就要到你刚刚安装sdk的路径下找到adb.exe,然后按Shift健 然后鼠标右键选择

现在有一些开放的平台提供这种测试的能力，还可以自己写编一些脚本去做，当然也可以用monkey测试来跑。

作为一个在软件和互联网行业浸润了20年的老兵，我接触了很多公司，也面试了很多人，发现国内现在能实现APP的UI自动化测试的公司很少，我的一个之前在淘宝测试团队工作的同事也讲，在淘宝也是部分实现了自动化测试，因为很多业务变化很快，实现自动化测试意义不大。我面试过的很多测试人员，有些是工作了快10年的也是这种观点。我们公司是一个创业型的汽车后市场O2O企业，因为老板的平台化战略，我们的APP非常庞大，安卓我们有5个APP，IOS我们有4个APP，功能覆盖洗车，保养，维修，拼车，租车，代驾，交友朋友圈等等，功能复杂度堪比淘宝，也不是我这里吹牛，大家下载看看就知道了，在应用宝搜索”逸休联盟”就可以看到了。

因为我们基于精兵战略，我们的开发和测试人数一直都很少，安卓和IOS开发巅峰时候也就是各自5个人，现在缩减到各自3人，测试人员从之前的2人变成了1人。因为是个创业公司，我们的业务现在还是非常不稳定，功能经常是变来变去，这也是很多创业公司遇到的，但我们还有2个困难，功能庞大，人员少，根据我的了解很多创业公司的功能比我们少很多，但人员多很多，提升开发效率和测试效率就变成了我们需要解决的问题。今天这里，我主要谈谈我们怎么样基于现在流行的Appium解决自动化测试的问题。

上面是我们APP的架构图，安卓和IOS都是相同的，独立组件层是一个重用性非常高的模块，只依赖安卓和IOS自身类库，和知名的类库，如百度地图等，这个模块可以脱离我们APP使用。在这个层上面，网络层是和后台进行交互的，一切数据请求包括图片都通过这个层面，我们学习了几个开源代码基础上面独自开发的，这样做的考虑有很多，这里不在多讲了，如果有兴趣，请关注我后面的文章。数据模型层用于和后台的数据交互，也同时用于APP界面的VIEW的交互。项目组件层是项目当中可以重用的组件，因为依赖数据模型，不能独立出来。最上面一层就是我们的插件层，就是具体的业务功能实现。

其实自动化测试需要解决下面几个棘手的问题：

1.    怎么样找到能够完成这个工作的人

2.    怎么应对频繁的业务变化和UI变化

3.    怎么样设置断言，怎么样建立标准库

我面试非常多的测试人员，发现真正懂自动化测试的人太难找，如果应要找就得去BAT挖人了，这当然是不现实的。很多测试人员是不会编程的，即使会编程，也是太低级的水平。我们的办法是测试人员和开发人员合作完成，开发人员编程能力很强，但他们不知道怎么去做测试，他们互相合作形成优势互补解决了人员问题。这个合作关系当中，测试人员就是产品经理，开发人员通过理解他们的测试用例，来形成需求文档设计。我们的目标是基于我们的APP，开发一个测试框架，这个测试框架具有很高的重用性，可以大大降低测试人员的编程门槛，他们只要简单的调用几行API就完成了测试，测试人员关注的是测试的流程和角度，不需要关心具体底层的实现。下面是我们的工程截图：

我们的测试工程包含了两个包，一个是开发人员维护的，一个测试人员维护的，开发人员去学习Appium框架和API，基于Appium设计和开发出我们自己的框架，同时可以测试IOS和安卓，测试人员不需要去关心这两个平台的区别，因为IOS和安卓的功能都是相同的，所以他们是可以只写一套测试代码的，下面是测试人员的代码：

虽然这是首页的更换城市，我们还有很多其它需要更换城市的地方，其实就是需要换个ID就行了，测试人员是知道怎么通过工具获得ID的，而且这些ID也是相对比较稳定的。

这是一个相对复杂的测试用例，对于测试人员只要知道理解我们的API就行了。

怎么样应对业务和UI的快速变化没有一个统一的解决办法，这是需要针对不同情况找不同的办法，但前提是我们需要对产品，开发和测试有个全局的考虑，从而发现解决的办法。因为我们的软件是基于组件化开发的，实现快速应变有着先天的优势。我们组件化提升我们的开发效率，同时在测试方面我们也应用了针对组件的组件化测试。下面我来举例说明一下，当然这只是我们解决的问题当中的2种类型：

搜索排序是一个非常常见的场景，所有电商APP都有这个场景，我们的也不例外，下面是一些我们的场景图：

上面两个图，一个是进行商家查询，一个是进行服务查询，这两个场景看似不同，但对我们测试框架来讲实现是一样的，没有区别，我们的界面都是组件化的。比如左边的截图包含了题头组件+地址选择组件+赛选组件+列表组件，右边截图也包含了相同的组件，我们的题头组件定义了很多不同展示形式，其实都是一种组件，因为我们的测试框架也是针对组件做的，自然就保证了测试用例的灵活性。上面的赛选排序测试用例就简化成了下面这样，就几行代码，我们的赛选条件可以只多级的，这个示例只是两级，如果我们要设置地区条件排序条件，则filter(“行政区，登州市”)，sort(“好评优先”)，写测试用例变得非常简单和直接，如下图所示：

其实这个赛选函数可以使用到很多地方，如车型选择，城市选择等等，我们的框架每个函数都是解决的一类问题，而不是一个问题，具有非常好的灵活性。

下面我讲讲怎么建立界面变化的问题，拿商家查询来讲，列表当中的每个CELL，产品那边是经常变化的，赛选条件也是经常变化的，赛选条件变化，我们就是把传入的参数变化一下就行了，对于CELL的变化有稍微复杂些。做过测试的人都知道，测试这个商家列表，我们可以从很多角度进行测试，角度有：排序和赛选条件是否正常工作，正常查询是否能进行，点击CELL是否能成功进入详情等等。

因为CELL是经常变化的，但CELL的变化会影响我们排序和赛选的测试用例吗？如果你使用截图对比方式，当然是影响的，因为你的CELL变化了，说明标准图例也必须变化，否则用例就是失效的。但如果我们使用逻辑进行判断呢？情况就完全不同了，我们的CELL可以任意变化，但商家名称这个字段是永远不变的，没有商家名称，这个列表也就没有意义了，所以可以讲这个字段是100%肯定不会变化的，那么通过截取列表当中商家名称的序列，我们就可以判断排序和赛选条件是否有问题。比如，一组赛选和排序条件设置后，我们希望的商家排序是：

汽车快修保养，盛大汽车装潢，大拇指汽车美容…

但实际上是：

汽车快修保养，大拇指汽车美容，盛大汽车装潢

通过对比两个LIST，我们就可以知道，排序和赛选逻辑是否发生了变化，程序是否出现了BUG，所以我们能做逻辑判断的地方，就不会使用图片对比判断。使用逻辑判断的另外一个好处就是，我们不需要考虑机器的适配性，安卓机器市面上太多了，每种机器的截图都是可能不同的，劳动量显然是我们这样做的几十倍。通过这个例子，我就是想说明一个道理，业务变化快是事实，但不能说自动化测试成本就会非常高，关键是产品+开发+测试的全局的思维和解决问题的方式。

断言的设置和标准库的建立也是一个比较棘手的问题。我们有一个自动化测试标准库，这个库有的是生产数据，有的是后台创建的数据，由后台团队进行维护和升级，这个数据库表结构和生产环境保持同步，就是生产环境的一个特制版本，可以支持生产流程当中的全部业务逻辑。为了保证自动化测试的可重复性，我们使用的DOCKER技术进行映像回滚，APP测试框架可以通过SOCKET连接远程触发数据库回滚和服务器代码回滚。有了标准数据库，下面就是怎么建立对比标的数据。

前些时间我面试了一个做测试的老兵，8年做测试的经验，曾经在阿里和百度都呆过，最后于2014年离开百度到了最近的一家公司。当时我问她的问题是，怎么继续断言的逻辑比对。她给我的答案是，他们测试团队也有开发，他们会编程从数据库读取数据，然后和APP的读取数据进行比对。这虽然是个解决办法，但测试人员需要有良好的开发技能，而且因为业务逻辑变化，他们测试团队读取数据库的方式也需要不断修改。我看过很多人的测试用例代码，包括一些国外的示范例子，很多人喜欢把测试断言判定条件直接写在代码上面，比如ASSERT(result==’example’)，这种Hardcode的方式重用性和维护性极差，我们的测试代码是绝对不允许这样做的。我们提出了一个标的数据集的概念，标的数据集就是你需要对比的标准值，这个标准值可以是一段文字，数字，一个字符串LIST（例如商家查询的对比标的），也可以是图片，可以是任何形式的数据，下面的数据就是怎么来建立这些标的数据集。之前我在网上看到一些例子，都是人工去处理的，人工去设置到EXCEL表格当中，人工截图然后放到指定的文件夹里面，每次业务逻辑变化，这个标的数据集的建立本身就是一个费力的事情。我们的解决办法是标的数据集建立的自动化，我们的框架里面有两个测试环境变量，一个是数据标定流程，一个是测试流程，测试流程不用讲了，标定流程其实就是自动化生成标准数据流程。当测试手工完成业务测试后，我们就认为现在的数据可以作为标的数据集了，会启动标的数据集流程，这个流程，系统会截取界面数据，或者自动截图，把这些数据保存在我们规定的目录之下。例如，前面的商家搜索案例，系统会把商家名字排序截取处理，保存到一个字符串LIST的数据集当中，同时也会截图手机图片，作为图像对比的标准图片，并且保存到对应的文件目录中。每个测试用例都需要加入一个数据标定流程，数据标定也提供了API，测试人员只要直接简单调用就行，他不需要关心数据是怎么截取的，怎么保存，或者保存到了什么地方，他都不需要关心，他只需要指定需要针对什么生成什么数据集。例如，商家搜索案例，测试需要指定，按照商家名称的ID，生成一个字符串LIST的数据集，其它的他都不需要去关心。

通过上面的一些措施，我们现在就一个测试人员来维护9个APP，如果有不能完成的测试用例流程，则让开发人员协助帮助他完成。当然基于人员储备考虑，我们后面会增加一个测试人员，保持2个测试人员水平。

app的自动化重点其实讲的还是功能上的自动化，通过编写代码去驱动程序运行，从而达到检测的效果，可以省去人工的重复点击，app的自动化可以借助于很多的工具来实现，当前最流行的appium，需要先掌握一定的Python或者是java语言能力，然后识别app上的控件，通过代码模拟单击，双击，滑动等相关操作，最后可以自动的生成报告，目前个人感觉最容易上手的app自动化工具是monkey，操作简单，容易理解，可以先从这个入手。