很多时候，我们只注意在了自动化的实现上，而忘记了对自动化测试的需求分析上，从而导致后期做出来的目录结构不合适，改动困难，debug难度高，自动化测试的首要特性就是重复执行，不能重复执行，且易暴露问题的自动化，不如手工测试。
我认为的自动化测试框架必有以下特征：
1.方便指定待测集合（用例、套件）运行
2.方便失败之后的debug过程
3.方便编写（建议用强类型语言）
4.与手工测试能互相呼应，能够很容易明白这条用例要做什么。就好比我们说英语一样，我不想要收到了英语的信息之后，通过翻译软件，告知我的大脑它的中文意思，然后我的大脑再在我的记忆之中找出对应的英语单词，最后由我的口发出。我希望是，我接受到了英语信息，我的大脑不需要把英文翻译成中文，而是直接明白英文的意思，并且用英文发出，整个过程不涉及翻译，所以建议不要搞花式的EXCEL关键字驱动或者其他形式的XX驱动，有这么一句话，show me the code
手工测试用例->自动化测试用例需求分析
我们在最初开发自动化测试框架的时候，一定要记住结合目前已有的手工用例，并且分析，最后定出我们自动化测试框架的结构，不然后期会吃大亏，就像产品人员根据已有竞品，分析出我们的开发需求一样，我们得分析我们的手工用例，定义我们的自动化测试框架需求。
这是一条常见的购物测试手工用例：
1.登录网站首页
2.输入用户名，密码
3.购买一款价值500元的产品
4.检查实际支付金额是否正确
期望结果：
实际支付金额正确。
用例看起来很简单。好像操作步骤也不复杂，应该是一条很容易自动化的测试用例。实际不然，我们在做自动化测试的时候，需要进行详细的分析。按照我们自动化的测试逻辑，分为@测试前（数据准备），@测试过程（执行测试步骤）@测试后（用例失败或成功的数据清理）。这条用例按照自动化的逻辑就变成：
@测试前
1.通过数据库插入语句生成一个用户，“用户名”“密码”固定，传入测试数据
2.通过数据库修改语句修改某产品的价格为500，返回“产品名”，传入测试数据
3.通过数据库修改语句修改已知的用户的账户余额大于500
@测试步骤
1.打开网站首页。在网站首页点击登录按钮
2.在登录弹出层输入“用户名”“密码”，按下确定按钮
3.在搜索框输入测试数据中的“产品名”点击搜索按钮
4.在搜索结果列表页点击第一个搜索结果的标题栏
5.在产品详情页点击加入购物车按钮，点击页面右上角的购物车按钮
6.在购物车页面点击立即结算按钮
7.在支付页面选择账户余额支付，完成支付
8.等待页面挑战提示支付成功字样
9.点击页面右上角会员中心按钮
10.在会员中心检查该订单的实际支付金额。获得订单号，传入测试数据
断言：实际支付金额==500
@测试后
1.根据用户名删除该用户
2.判断是否存在订单号，存在则删除订单表中的该订单数据
3.修改购买的该产品的价格为原价
所以，根据上面的用例，我们可以分析出，我们的测试框架有
--测试用例
--测试页面库
--测试动作库
--测试结果校验库
--组合测试步骤库
--其他工具库（包含数据库操作，API操作等）
流程是：
在通过某些工具准备好数据之后，每一个测试用例包含多个测试步骤。每一个测试步骤会在一个测试页面上进行多次动作。操作多个页面元素。操作完成后会经过一到多个测试结果检查。完成测试结果之后，告诉测试基类这次测试的结果是正确还是错误，记录在日志之中。最后在完成所有测试集合之后，最后统一通过邮件发送出来。
在明确业务流程后，完成自动化测试就是具体的落实工作。如果后续有时间，我会发出我推荐的自动化测试代码框架。
我的建议是用testng+ selenide+ ExtentReports+jenkins+maven+jdbc+httpclient这些工具做自动化应该是比较好的，对于mybatis ,dom4j ,poi这些我感觉是用不到的，我曾经加入过excle,xml等一些貌似很合情合理的功能，但是后续在用例失败debug的时候简直让我爆炸，自动化测试，一切从简，能用代码解决的，就不要用其他工具。
