Appium python自动化测试系列之移动自动化测试前提（一）

1.1 移动自动化测试现状

因为软件行业越来越发达，用户的接受度也在不断提高，所以对软件质量的要求也随之提高，当然这个也要分行业，但这个还是包含了大部分。因为成本、质量的变化现在对自动化测试的重视度越来越高，在几年前自动化测试还没有像现在这么普及，但是现在随便去一家公司面试都会问到自动化测试，当然这个和他们公司是否运用到另说。但是不言而喻的是大家都意识到了软件测试这个行业都走向了自动化这条路。或许你认为实施自动化可能不是必须的，可能在你的观念中测试思想是最重要的，所谓的自动化工具或者框架都是用来辅助的，但是作者想告诉你的是：计算机行业的发展、软件测试行业的发展其实就像工业革命一样，为的是通过此途径解决人类手工劳动的复杂性，当然可能并不一定是这几年出现，但是如果我们不学习肯定会被时代淘汰。对于现在的我们来说自动化测试是我们必须掌握的技能，同时它也是这个行业的一种发展趋势，当然你想要提高到更高的一个档次可以往测试开发走，我坚信你能够走得更远。

1.2 本课程目标

因为作者也是从一个初学者过来的，而且在初学的过程中走了许多的弯路，所以作者希望通过本书带领读者从一个初级用户到高级用户，从不会到自己能够独挡一面。

我们共同的目的是先掌握android的基础知识、appium相关环境知识、python的基础知识、常见api的使用以及封装、日志的收集、报告的生成、再是我们常用的数据驱动、页面驱动，还有后面的nose框架的介绍以及使用。 

整个书的目标是希望读者真的能够只是通过本书的知识就能够完全掌握appium相关的自动化知识，成为大家跳槽涨薪的必备技能。光说不练也不行，所以作者希望大家看本书时跟着一起敲代码，熟能生巧。

1.3 自动化测试流程

无论在做什么事情之前都需要掌握其流程，自动化也是一样，我们首先要掌握的就是流程，如果你连最起码的流程都无法掌握，那么你也没办法做好自动化。作者将通过自己的项目经验来写，当然这个不一定就是标准的答案，所以如果有觉得不符合的也不要吐槽，可以提出来一起讨论。

我们通过下面的图片来了解

可能有的人会有疑问说：这个怎么看就是一个v模型呢？这个作者只是为了让大家更容易理解这样编写的。可能还有人会说我们做自动化为什么不是直接拿着需求就开始写代码，浪费那么多时间去做其他的有什么好处呢？我们来一 一讲解。

1、需求了解：当给你一个需求或者一个系统让你去做自动化的时候你什么都不知道你就去做自动化能行吗？你不去分析需求或者系统的哪些模块儿适合做自动化你怎么去做？如果盲目的去做，当你做到后面的时候可能你框架还没弄好需求或者系统又变了，那你是否做了无用功？所以我们第一步一定是确定需求或者系统哪些模块适合做自动化，而且一定要明白这个需求或者系统做自动化给我们带来的好处是什么，而不是说做自动化就是为了表示我们会做。

2、需求分析：和需求了解有类似之处，我们在这个期间主要做的就是分析需求或者系统哪些模块适合做自动化，做自动化给我们的好处是什么，为后期方案提供参考，提供可用信息。

3、方案选择：有的人可能对选择方案会比较陌生，不知道这个到底是干什么的？那么问你一个很简单的问题，现在自动化测试框架常见的有robotium、appium、monkeyrunnner、UIAutomator等等，这么多的框架你为什么选择学习appium呢？其实这就是一个方案的选择，那么有时候你也会根据你项目的需求去选择一个更加适合的框架，让我们这个需求实现利益最大化。

4、环境准备：这个最好理解，方案选择好之后就该准备环境了。这个环境不会像大家想的那样配置一个jdk、appium、ide就行了，你需要考虑的是appium的版本、持续集成、代码管理等等问题，这个详细内容在后面框架部分作者会讲到。

5、系统设计：刚开始接触自动化的小伙伴可能对这个比较陌生，不知道什么叫做系统设计，不用担心。在做自动化的时候大家是否考虑过一个问题：在自动化过程中我们公用的东西是怎么提取出来的，为什么要按照不同的包结构来进行框架搭建，为什么不能够是所有的都在一个包下或者一个类下面？我们简单的看一下下面这个图片

 

从图片中我们能够看出在这个工程中我们有专门存放app的地方，有单独的配置文件、case、以及读取配置文件的地方，共同的特点就是他们都没有在一起，这还只是一个简单的例子，在以后我们的工作中这个是最常见的，在开发之前我们就需要把这些规划好，因为一个项目往往是一个团队来做，那么大家肯定是先划分模块，分工，在后期还会涉及到一些模块间的调用。目的就是让我们一目了然的就知道这个包是做什么的，把公用的都提取了，各司其能。

6、编码：编码故名思意就是编写代码，只是这里我们的编写代码是根据事先写好的用例来进行编写代码。

笔者在这里说一个题外话，这个也是很多初学者会面临的一个问题，这也是为什么很多人看了一些自动化的资料但是一直无法做自动化的原因。在很多的公司自动化会分两个组，一个是开发测试框架，一个是写测试用例，这里的测试用例是自动化的case，不要理解错。

7、执行：执行是整个自动化展示成果的重要一部，最后的结果我们看到的是执行了多少case，通过多少，通过率是多少，失败的为什么失败。这也是领导或者其他相关人员想看到的数据。

那么为了这一步我们的自动化要做多少准备呢？作者会在本书中一 一给大家讲解。

1.4 自动化测试用例的编写

自动化测试用例和我们常用的功能测试用例虽说区别不是很大，但还是有一定的区别，下面我们用登陆功能来举例：

功能冒烟用例：

（备注：因为格式原因所以表格里面没办法调整，用例中步骤1=>1，以此类推）

 

上面图片就是一个简单登陆冒烟测试，自动化的用例不同之处在于更仔细。来我们直接通过下面的用例来给大家讲解：

自动化登陆用例：

通过上面的用例我们不难看出自动化和功能测试用例最大的区别在于自动化要求更详细，信息更加准确，当然这个并不是完全标准的，这个只是作者在工作中和接触的人中大家基本都用的类似用例。很多公司设计用例的和将用例转换为自动化脚本的并不一定是同一个人，所以我们需要保证的是别人看见你的自动化测试用例能够准确的编写出测试脚本，这也是我们的目的。