--------手机自动化之Appium
今天翻了一下博客，发现这个Appium+python的手机自动化测试教程还没有写完呢！上一章写的是时候是十月份，后来忙来忙去也就没有顾上写了。在公司努力补充自己的不足之处，学了不少以前不会的东西。平时也在尝试着自己的做一些儿其他的事情，虽然15年过的有不如意的地方，但总体还说还算不错。在这最近几个月算是对15年做了个总结吧，16年毕然是一个开心幸福，充满希望的一年。
闲话不多说了，通过我们前五章的介绍，我们了解了什么是Appium，Appium+python测试环境的搭建，Appium Api函数，真机运行测试用例以及如何定位手机app的元素。通过这几章的内容，你应该可以编写自己的自动化测试用例，将手工测试用例转化成python语言编写的测试脚本并能运行成功。可是如果让你从零开始对一个app做自动化测试，你仍然会感觉到无从下手，那应该如何实施一个自动化测试工程呢？
6.1 手机自动化测试工程实施的步骤
一个好的自动化测试开发工程师，需要做的不仅仅是能将手工自动化测试用例转化成脚本编写的自动化测试脚本。而是需要将自动化测试实施成一个完整的工程项目，并且能传承下去，根据不同的业务需要来进行灵活的使用。所以在实施之前还是要考虑很好事情，下面都是我们要考虑的问题及实施步骤：
（1）熟悉被测试应用的业务
（2）分析并提出测试用例
（3）规划自动化测试工程
（4）设计自动化测试工程的架构
（5）编写自动化测试用例代码
6.2熟悉被测试应用的业务
孙子曰：“知已知彼，百战不殆。”在我们做自动化测试的时候也是一样的，在我们不了解公司业务的时候，接到一个要实施自动化测试的时候，你不可能马上就开始写代码吧？
在你在公司接到实施自动化测试的时候，首先要考虑的问题不是用什么框架，什么语言来编写测试用例。而是要梳理一下业务流程，主要的业务是什么，应该怎么操作？哪些儿是主要业务？主业务流上的用户压力有多大等等 。这些儿问题你要搞清楚，如果有相关的业务流程图，好好熟悉一下。如果没有，就找业务比较熟悉的同事去请教，自己画出业务流程图来。
这个阶段是和代码没有任何关系的，所以这个阶段的产出就是业务流程图，把业务理清楚。然后分析出重点业务，核心流程，把这些儿都搞清楚，罗列出来，此阶段就算完成。
6.3分析并提出测试用例
在了解了业务逻辑后，就要提取重点业务，核心流程的测试用例，这个是我们做自动化测试的前提。自动化测试工程是很庞大的，所以不可能一下子就完成的，得分个主次。第一个版本需要覆盖哪些儿业务，哪些儿用例就是此时需要分析的。
在开始做自动化测试的时候，首先需要覆盖重点业务的核心用例，像下面这几种测试用例是无法实现自动化的：
（1） 支付相关的测试用例。
很多公司自己没有在线支付的资格的，所用到的支付都是第三方支付，测试的时候只测试到支付页就可以了，再往下测试就到第三方了，没有这个必要。而且支付一般是真实支付，这运行一遍支付一次，花的钱有人报销不？
(2)验证码相关测试用例。
目前在注册，快速登录这一块都会引入验证码验证，有的时候图形码，有的是手机短信验证码，目的就是防止恶意注册或是刷新。这一块一直是自动化测试的软肋，有两种方法可以实现，对于图形验证码，一是利用图形识别技术，二是添加万能码！对于手机验证码，一是调用短信接口，获取短信内容，二是添加万能码。当然这是非正常的手段，以应付必须编写测试用例的时候，这类用例尽量避免。
（3）样式相关的测试用例。
自动化测试用例是注重业务逻辑的，我们用例代码来替代人工来做业务逻辑的回归，对于样式相关的测试用例，是无法用代码来完成检测的。这类测试用例也是在自动化测试用例排除在外的，不要考虑这类用例是如何编写的。
排除了以上几种测试用例，我们挑选出适合做自动化测试的测试用例，然后分出主次，分批次完成我们的自动化测试工程。
6.4规划自动化测试工程
通过上面的分析，我们已经完全了解了我们要测试的对象业务逻辑，要编写的测试用例的范围及相应的时间等，可以说到了开展我们的自动化测试工程的阶段了。此时也要不着急，规划一下我们的自动化测试工程，这个规划不是代码级别的，而是人员级别的。
(1) 工程性质。这个自动化测试工程的使用场景是什么？这个工程是个人开发，还是由一个团队开发？团队规模有多大？这些儿都是需要提前考虑的，然后才能更好地规划出工程的架构 ，开发模式及规则等。
(2) 团队的性质。你这个开发团队是什么水平？大家擅长什么语言？哪些儿人能做架构设计，哪些儿人能补充具体的代码，又有哪些儿人能检测代码存在的bug?这些儿也是需要考虑的。
(3) 框架的性质。我们要做的自动化测试工程，目前市场上哪些开源的框架，它们的优缺点是什么？支持团队是什么情况？更新速度如何？这些直接关系着我们后续的工程进展的程度。
(4) 编码规则。团队开发必须有统一的编码规则，不然你写的我看不懂，我写的你又看不明白，那还怎么合作共事啊？虽然前面我们强调编码规则会挺讨厌的，但是等大家都习惯后，就能发现其中的好处。
6.5设计自动化测试工程的架构
在规划好了自动化测试工程后，我们就需要设计自动化测试工程的架构了。说起架构感觉有点儿玄乎，不太明白，其实我们可以换个说法：就是如何管理你的自动化测试用例？
自动化测试维护成本是相当高的，被测试对象的任何变动都有可能影响到我们的自动化测试用例。而使用场景也不同，如测试环境回归测试，仿真环境回归测试，线上场景回归测试和监控需求等，都要求我们提前需要对测试工程进行有效的设计。方便我们维护测试用例，灵活使用测试用例。
为了达到这个目的，我们对我们的自动化测试工程进行如下的架构设计：
（1） 公用函数层，CommonFunction:这一层相当于一个package,用来存放所有测试用例都用到的公用方法，公用类，数据操作等。
（2） 测试用例层，TestCases:本层存放具体的测试用例，通过调用公用函数，读取测试数据来完成相应的自动化测试用例。而每个具体的测试用例文件中，没有相应的测试数据及操作，只是具体的用例流程。
（3） 测试数据层，TestData：存放具体测试用例用到的测试数据，每个测试数据文件对应一个测试用例文件，在测试用例中进行区分。测试用例文件和测试数据文件同名，同一类测试数据可以放到一个文件中。
（4） 测试用例集，TestSuites：不同的测试用例的使用场景不同，我们可以根据需要来组织不同的测试用例集，产生测试报告等操作。
经过上面的四层划分后，我们的测试工程如图6.5.1所示：
图6.5.1 四层架构的自动化测试工程
四层架构的优点：
（1） 减少代码量。引入了通用函数层，我们可以提取出所有公共操作，然后再写具体的测试用例的时候，我们只需要调用公共函数组合用例就可以了。前期需要补充公用函数 ，后期用例只需要调用即可。
（2） 便于维护。自动化测试用例的维护一般都是测试数据的维护，操作步骤的维护。而在我们这个架构下，维护测试数据只需要修改testdata层中的文件；维护操作步骤，只需要修改testCases中的函数调试，清晰明了。
（3） 使用灵活。通过在testsuites层创建不同的测试用例集文件，我们可以灵活地组织我们的测试用例。在不同的场景下，调用不同的测试用例集。
（4） 便于团队开发。大家可以在同一的架构下开发不同业务线的测试用例，可以统一使用公用函数，但前提是大家一定要统一编码规范，添加详细的注释。