前言

本文主要阐明笔者对于UI自动化建立的流程总结，不涉及具体的代码编写，主要在表达思想。具体的代码编写另写文章记录。

目的

在上线新功能的时候都需要对网站的主要流程做一遍回归测试，已确保新改动不会对旧功能造成影响。引入UI的自动化，可以有效减少重复人力劳动，节约时间，提高效率。

那么从哪开始呢？

首先，针对自己的需求和能力，选择一个好的工具和框架。我选的是selenium Webdriver使用python语言。机缘巧合下知道了一个叫做bok-choy的框架，其实就是用 Page Object模式封装的selenium。比自己以前写的框架好用，所以学会选择工具很重要，选择一个好用的开源框架比自己去写好多了，毕竟绝大多数情况下一群人的智慧要胜过一个人的智慧，不要去重复造轮子。不过，抱着学习的心态去自己写一个框架就另说了。
写一个自动化的测试用例往往需要考虑以下几个问题。

• 为了达到这个测试的条件，我需要造哪些数据？
• 功能点都包括哪些步骤？
• 需要验证哪些东西才能保证这个功能是通过的？

所以，第二步，需要列出回归流程的功能点并进行归纳分析。

用例前置条件

写用例前需要总结出用例需要的前置数据。比如，我要测试一个学生报名考试的功能，步骤是学生登录->在考试列表选择一门考试点报名->填写报名信息并提交。那么，首先需要有用户数据用来做登录操作，接着还需要考试数据。这样，登录用户在进入考试报名列表页的时候，才可以确保一定有考试可以给这个用户报名。
前置数据的创造有几种做法：
1.用UI自动化的方式去相应页面创建；
2.用调用API的方式去创建；
3.直接操作数据库来创建。
第一种方式，我不推荐，因为UI方式去创建速度慢，流程长，不确定性大，容易失败影响测试。第二种方法是目前我使用的方式，因为速度快，出错率低。第三种方式一般是在没有api调用的情况下去使用。比如，需要测一个用户在付完费之后才有的功能，用户订单从未支付状态变为已支付状态这种操作不可能提供外部接口，因而需要自己按照相应的业务逻辑直接从数据库将订单数据造出来。如此一来，我们可以建立一个模块，假设叫datafactory，专门用来造数据。具体用例需要用到的前置数据，都通过调用该模块的方法来创建。

写用例

第三步，着手写具体的测试步骤代码。具体代码的书写，本文不介绍。如何使用selenium+python写UI自动化，可参看bok-choy(selenium+python+page object)使用介绍

测试的验证

接下来，需要写测试的验证。一个完整的测试必须包含验证部分。本人用到的验证一般是操作步骤完成后，去验证某个页面某些元素或者字段是否存在。比如，新建一个考试的功能在UI 层面的操作做完之后，验证部分是去列表页面检测包含考试名称的文字是否存在于页面上（考试名称每次都会随机化）。也听说有人在测试验证部分是查数据库来验证的，不过我认为UI自动化的验证能在页面上验证就用页面验证，毕竟这最符合用户的使用场景。

测试中的错误处理

写了具体的一些测试代码之后，需要考虑:
测试在运行过程中如果失败或者出错了怎么办？
如何确保事后能快速地定位问题？
这时候需要必要的log和截图。如果是自己写框架这需要自己设计。不过直接用一个好框架，比如bok choy这些框架本身会去做，只要知道如何使用即可。

测试的运行

经过以上的步骤，测试代码应该是可以运行起来了。不过还有一些问题需要考虑：
这些测试都在什么情况下去跑？
定时自动跑还是手动执行？或者是符合某些条件后自动触发执行？
这些问题都需要根据自己公司的实际情况去考虑。
现在很多公司都在开展持续集成，持续集成的流程一般都是特定条件下的代码变更触发部署任务，在测试机上部署新代码，部署完之后接着触发测试任务，测试任务可包括但不限于单元测试、接口测试和UI测试。测试通过则进入准备发布的状态/合并到分支，不通过则回滚/拒绝合并。做持续集成，Jenkins的用户量应该是很大的。Jenkins里建project的设置里有个"源码管理"部分，这部分可以监测代码变动从而触发相应任务。可参见Jenkins+git+webhook自动触发部署和测试任务

测试报告

测试跑完需要有一个测试报告。在python中unittest默认跑测试只有一个标准输出，不便于测试结果的长期保存。python的第三方库nose（封装unittest）可提供输出xunit格式的报告(Xml格式)，这种报告可被Jenkins很好的识别，便于展示测试状态(成功还是失败)，从而根据状态触发下一步动作。不过这种xml格式对人不够友好，不够"好看"。所以，如果是人来看测试结果的话，还有一种更好的选择，即HTMLTestRunner来跑测试生成报告。它会生成一个html格式的文件，失败、成功和错误都用不同的颜色去显示，通过自己改编源码还可以把截图加进去便于查看。

测试的分布式执行

随着写的测试越来越多，运行时间可能会非常长。不过一般UI测试的量不会特别多，主要还是应该在单元测试那一层做更多的测试。如果UI层面确实有很多测试，就得考虑分布式执行的问题。这方面我没有实践过，但selenium grid可以解决;还有就是jenkins中的Maser-slaver模式也可以解决，只需要自己想办法把用例分份，然后各个机器上的结果想办法合并。

总语

以上就是我在建立WebUI自动化过程中的一些经验总结，涵盖了大部分问题。希望对看到的测试小伙伴们有帮助吧~