第六章 自动测试实施(上)
---Web自动化测试之Webdriver(python)--从零到熟练（系列）
从本章开始，我们将讲述如何实施自动化测试，在第一章的时候，我们也提供了自动化实施的步骤。那些儿步骤是指导方针，可以按着这一步步地去实施，可是有点儿笼统。本章我们将从具体实例入手，按前面的我们提到的步骤来讲解，通过本章的学习，你可以从一个被测试的网站着手，从零开始建立起普通的回归测试用例。
6.1 评审被测试对象功能
现在你的老大给你分配个任务：我们公司的业务已经成熟，网站主要功能也基本上不会变化了，我们想在每次上线后自动回归一下主功能。所以呢，我们想让你对我们的网站建立起自动化测试，用例要求覆盖主要功能。
当你接到这个任务的时候，你应该如何去做呢？不是去想用什么来写自动化，或是马上用你擅长的语言马上就去写测试脚本。而是要先分析一下被测网站的功能，哪些儿是主要的，哪些儿必须自动化，哪些儿不能自动化。
现在我们以众筹网（www.zhongchou.cn）为例 ，分析一下主要功能：
（1）登录注册
（2）浏览项目
（3）搜索项目
（4）查看项目详情
（5）支持项目
（6）个人信息设置
（7）发起项目
（8）查看自己相关的项目
（9）发起的项目管理和订单发货
（10）消息中心
等等 ，这十个主要功能是网站最基本的功能，然后我们分析一下哪些儿能自动化，哪些儿不能？
能自动化的部分：1，2，3，4，6，8，10
不能自动化的部分：5，7，9
为什么不能自动化呢？5，支持项目，涉及到真实的支付，影响项目对账，因为不管是测试环境还是线上环境，都是真实的支付，如果有支付的测试环境，也是可以自动化的。
7，发起项目，发起项目通过审核后，会在线上产生测试数据，影响用户体验。这违反了测试不能对线上产生垃圾数据的原则，所不不建议自动化，但是可以测试发起项目的流程，不对项目进行上线。
9，发起的项目管理和订单发货。发起项目我们就没有自动化，所以这块功能是没有数据的，再者订单发货会短信通知支持者，会影响到用户，不建议自动化。
当你接到任何一个测试任务的时候，需要先这样分析一下被测试对象的功能及是否合适自动化测试。然后查找一下是否存在对应功能的手工测试用例，一般公司都会做测试用例的收集工作的。如果没有，就先编写对应的测试用例，然后再去转化成自动化测试用例。
6.2 评审被测对象编码
评审完了主功能，然后开始评审被测试对象的编码，选择与被测试对象相同或是同一系列的脚本语言来写测试用例。一般网站编码无非是ASP.NET,PHP,JSP等，编写测试用例的脚本语言也可以用php,python,java等，根据实际情况，做出相应的选择。
经查看，我们的众筹网是用php编写的，按原则来说，我们应该用php来编写测试用例。Webdriver也支持php,但是php支持库不多，在用例组织和报告生成等方面也存在着不足，所以目前用php编写自动化测试用例的不多。综合考虑各种因素，我们决定用python来编写自动化测试用例。
6.3 自动化测试框架的选择
目前业界做页面自动化的都是选用selenium1.0 RC或是selenium2.0(webdriver),而它们之间是存在着区别的：
Selenium RC 工作原理：
（1）RC server 在服务端启动 浏览器 并将Core 注入到浏览器中 （为了解决浏览器的同源策略）
（2）我们的测试脚本调用Client API，Client将操作转化成标准的selenese语句发送给RC Server。
（3）Selenium Core 解释selenese 语句，通过js的方式操作浏览器。
Webdriver 工作原理：
（1）WebDriver 启动目标浏览器，并绑定到指定端口。该启动的浏览器实例，做为web driver的remote server。
（2）Client 端通过CommandExcuter 发送HTTPRequest 给remote server 的侦听端口（通信协议： the webriver wire protocol）。
（3）Remote server 需要依赖原生的浏览器组件（如：IEDriver.dll,chromedriver.exe），来转化转化浏览器的native调用。
那么remote server端的这些功能是如何实现的呢？答案是浏览器实现了webdriver的统一接口，这样client就可以通过统一的restful的接口去进行浏览器的自动化操作。目前webdriver支持ie, chrome, firefox, opera等主流浏览器，其主要原因是这些浏览器实现了webdriver约定的各种接口。
优缺点：
（1）RC 需要启动一个 RCserver，就直观感觉上多了一个步骤。
（2）RC 采用js 的方式，稳定性和兼容行方面还是取决与js的代码的质量。有时需要自己去写js代码来扩展相应的功能。由于自己是从RC用起的，对于RC js的方式还是比较接受，感觉比较灵活。
（3）至于弹出对话框和警告框的处理，RC原生是不支持的。不过可以通过第三方软件来解决，比如autoit。我用的就是autoit，使用简单方便，是一个不错的工具。
通过上面的分析，结合现在的时代潮流，我们采用高版本的selenium 2.0来作为我们的自动化测试的框架。
6.4 自动化测试用例运行环境
由于我们采用的是python开发的脚本语言，对运行环境要求不是太高，可是相应的包还是要安装的。在脚本编写期间，我们一般是在自己机器上编写和调试的，运行环境是windows环境。在后期的交付运行，自动执行回归的时候，我们要放到服务器上，服务器是linux环境的。
在Windows环境和linux环境下，python运行环境差别不大，所以不要太担心环境的问题。可是也有需要注意的地方，比如说文件路径的写法，两个环境下还是不同的。这也是我们一再要求用相对路径，最好用函数来获取路径，而不是把路径写死到代码中的原因。
6.5 自动化代码架构的规划
任何一个好的程序，都需要有好的规划。考虑到现在的结构化程序设计，我们的自动化测试代码也需要好好规划一下架构，不能像记流水帐似的按测试用例的步骤罗列下来。
6.5.1 代码架构规划的原因
自动化测试用例的主要工作就是回归测试，由于其任务的特殊性，就决定了自动化测试用例是成体系的，大里的自动化测试用例放在一起，如果不好好规划一下，会给后期的工作带来很大的影响。
代码规划的原因：
（1）增加可读性。根据用途，将代码进行分类存放，方便团队其他成员进行代码管理与合作开发。
（2）便于维护。自动化测试用例不可能是一成不变的，被测试的网站变化了，我们对应的自动化测试用例也要进行相应的维护。如果不进行规划，出现问题后不方便定位，更加会耗费大量的成本去维护。
（3）提高代码利用率。结构化程序设计，要求我们对代码重复利用率要高，同样的代码要写在公用函数或是方便，减少代码量。
6.5.2 如何规划代码架构
目前自动化的用法主要有两种：1，简单录制回放转化成的测试用例，此用例用于反复测试的功能点，一旦功能上线后便不再用。目地是加快回归测试的执行。特点就是对功能进行反复测试，不考虑通用性，健壮性等。2，用于回归测试的系统化的测试用例。此种用例是需要反复执行的，一定要考虑程序的通用性，健壮性以及执行时间等。
针对第一种测试用例，虽然使用时间比较短，通用率也不高，不过有些儿公司还是会收集这样的测试用例的，以便以后同样的或是类似的功能回归测试的时候用。此时可以按业务线对测试用例进行存放，测试用例中包含测试脚本和测试数据。
回归测试自动化测试用例是我们的重点，所以我们要详细规划一下：
（1）为了增加代码的通用性，我们把大部分测试用例需要执行的操作步骤封装成函数，放到公共的类中，并把公共的类也按功能进行分类，统一放到一个文件夹下，如CommonFunction.
（2）将所有的测试用例放到一个文件夹下，测试用例与测试数据分离开，以便网站有变化的时候，我们只需要修改相应该的测试数据即可。测试用例放到一个文件夹下，如：TestCases。
（3）测试数据放到和测试用例同名的Xml文件中，然后通过公用的数据读取方法，对测试数据进行读取，然后在测试用例中调用通用的函数，读取到的数据传递过去。所有数据存放到统一的文件夹下，如：TestData.
（4）测试用例集的存放。由于不同的测试目的，我们会运行不同的测试用例。如果测试目的A,我们将运行测试用例1，2，3；测试目的B ,我们运行测试用例1,3,4,5。所以我们会有不同的测试用例集文件，将这些儿文件统一存放到一个文件夹下，如：TestSuites.
（5）其他的资源文件，可以创建不同的文件夹来进行存放，如图片文件夹image.
所以，经过规划后，我们的测试用例结构如图6.5.2所示，图中的文件是我先前写的测试用例。下面的章节，我们会具体讲述测试用例：
图6.5.2
自动化测试用例代码结构规划
