前期做了一个关键字驱动模型的WEB自动化项目，特意写文章归纳和总结下。
框架架构图
已经实现的部分：
1. 读写excel数据模板
2.配置中心，支持properties,xml格式的配置文件
3.参数传递没做，一般不建议在用例里面使用，比较麻烦。 不过添加了WEB页面 字符串和数值传递的方法
4. 设置了全局变量
5.监听器没做，错误重试在部分重要用例有做retry，提供了retry 方法
6. 断言有调用原生的Assert, 自己有封装了一些基本的验证方法。用例调用了TestNg
7. Json提供了多种方法，按照json层次访问数据； 遍历json； string转json , xml 转Json 等等
8. 测试报告采用的方法为： 定制一个Js 的模板template， 然后将testng中产生的数据传入到模板，再转换成html 。 报告中包含详细信息和汇总数据，这里要感谢张飞提供的原生Template
如图（以接口自动化测试报告为例，WEB自动化测试需要修改下详细数据的显示模式，归并步骤和通过结果等等，但是大体是可以沿用的）：
框架介绍
目前由于服务器没到位，执行层还未实现！
框架优势：
1 编写Case效率
-
易编写，在Excel内编写负责 粘贴非常简单方便，全局替换也非常方便。
-
易维护，无需每个人写代码脚本，在用例模板内可维护性高很多。
-
易交接，自动化模板基本都能看懂，思路一目了然。
2. 框架轻便灵活，无缝对接 持续集成，持续交付
3. 与TestNG +Maven+Jenkins 搭建持续集成链路，非常简单。
缺陷：
1. 一直想将页面元素与用例解耦，还没做，方案有：
a. 让测试人员将page element存储到另外一个excel，然后循环执行用例的时候去这个excel文件里面获取对应元素的定位信息。不过这无疑增加了IO消耗，
执行效率低下
b. 在程序里面设置一个xml文件来储存page element，然后写一个读取xml文件的方法来支撑用例运行
2. 开发的页面UI元素编写不规范，目前写用例和调试非常的困难。。。相信这也是大部分不成熟团队的疼点，只能通过和开发一直沟通规范了。
注： 文中的部分图片借用了 TesterHome 的 @testly (testly) 大大，我的思路和他类似~，但是不会画图。