前期做了一个关键字驱动模型的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) 大大，我的思路和他类似~，但是不会画图。