避免重复造轮子的UI自动化测试框架开发

一懒起来就好久没更新文章了,其实懒也还是因为忙,今年上半年的加班赶上了去年一年的加班,加班不息啊,好了吐槽完就写写一直打算继续的自动化开发

目前各种UI测试框架层出不穷,但是万变不离其宗,驱动PC浏览器的基本上底层都是selenium,驱动无线app和浏览器基本是appium、monkey之类的,底层都是基于官方支持的自动化测试框架开发而来,然后上层又做了各种封装

      首先在开始计划开发自动化时,第一步是了解目前已有的自动化开发技术,上面说了,最底层的就那几种,根据实际要去测试的业务需求选择合适的自动化框架,如我这边要负责pc、无线m站、无线app(android、ios)四个大用户入口的自动化测试,同时考虑整个研发团队的技术背景以及组内测试人员的技术背景,选择了pc基于selenium开发,无线端基于appium开发;开发语言选择java,因为我的基础开发语言一直使用java,研发团队有java、php开发,遇到问题也好请教人;然后上面要考虑自动化测试用例如何管理,测试基础数据如何管理,测试结果如何反馈,即知道这个用例执行成功还是错误,如果是错误了,什么原因,这里我采用基于junit单元测试框架来管理测试用例,为啥没选择testng,因为我最熟悉junit,并且后面还要说的一个原因是,自动化需要持续运行,不被特地人员或者需要什么特殊技能才能运行,所以要有个持续集成框架的支持,自然的选择了jenkins,然后写的用例要构建编译,这里直接选择了ant,为啥呢,因为上面说了 ant+junit 可以直接生成测试报告,省得再去写一个测试报告管理系统了,避免重复造轮子

      整个系统选型后的技术框架如下所示了

UI自动化测试框架技术模型

    上面说了,所有测试用例最后都要返回用例执行结果,json数据格式,boolean对象success来标记用例执行情况,然后就可以junit里使用assert断言用例执行情况,当然同时我们也可以讲结果保存到数据库或者本地文件中,方便后面的分析,我们没做数据库保存这块,时间不够,后面有时间再开发了

  上面还遗漏了一点,测试用例需要测试基础数据,这些数据从那边读取呢?testng支持从本地配置文件读取,junit要麻烦些,自己写从本地读取文件功能,可以在beforeclass中完成,但是由于要持续集成测试,肯定不能每次数据有变化,要再去更新文件,commit到代码分支吧,可以这么做但是由于测试数据经常要更新也需要没安装svn、git的人也能执行他们想要的用例,所以我们在原来的一个管理配置的系统上增加了一个web页面,所有测试基础数据在web配置,每次运行用例,测试用例到这边更新最近要运行的数据即可。

  数据流程图如下

UI自动化测试框架技术数据流程

 

如上基本上搭建完成了一个合格的可持续集成UI测试框架,当然了这个框架只要替换底层用例,也可以改成接口interface测试框架,这个目前只调研了下可行性,还没实施,估计还要踩不少坑

以上就是一个除了为了方便管理测试基础数据,其他都是使用现有轮子配件搭建起来的一个框架了

欢迎有其他更好实施方案的人员相互交流,共同提高

posted on 2017-01-07 18:01  MonLey  阅读(1001)  评论(0编辑  收藏  举报

导航