Lego测试平台05-网站篇

内部版:https://wiki.sankuai.com/x/Q0eYOg

本章开始介绍Lego网站部分的内容。

1. 组成

在“脚本篇”中,我贴出了一张目前Lego组成的图:

目前Lego由五个不同的项目组成,分别是“测试脚本”、“Lego-web页面项目”、“用于执行接口测试的base包”、“小工具集合Lego-kit”和“lego-job”,通过上图可以看出各项目间的依赖关系。

细化各个项目的功能,就是下图:

结合之前的文章,大家应该知道这个平台到底是什么样的东西了。

  • 为了减少开发成本,使用Jenkins+Java+TestNG+ReportNG的形式进行用例的执行。
  • 为了便于管理测试用例数据,使用DB进行测试用例相关数据的存储。
  • 为了减低维护成本,开发web页面进行用例维护。
  • 为了增加用例的健壮性,设计了“参数化”、“前后置动作”等灵活的参数替换。
  • 为了易用和兼容各种类型用例的接口类型的设计,统一“检查点”的使用。
  • 为了接口自动化用例设计提供方向,结合Jacoco做代码覆盖率统计。
  • 为了便于覆盖率配置,开发“代码覆盖率配置辅助工具”。
  • 为了便于分析数据,从DOM、CAT、Jenkins上爬各种数据,在页面上用Echarts展示。
  • 为了加快日常维护速度,从网页、Jenkins、Email报告上都可以直接进入某条需要维护的用例页面,进行维护,维护一条用例成本在几分钟内。
  • 等等等等还有很多各种各样便于做接口自动化的设计。

将各部分像“乐高积木”一样组装在了一起,使接口自动化在日常使用的过程中,更高效、快捷和可靠。

下面我将介绍一下网站方面的使用和设计。

 

2.站点开发

既然打算做工具平台了,就得设计方方面面,可惜人手和时间上的不足,只能我一人利用下班时间进行开发。也算是担任了Lego平台的产品、后端开发、前端开发、运维和测试等各种角色。

Jenkins+TestNG+ReportNG+我自己开发的基本接口自动化测试Base jar包,基本上没什么太大难度。但是站点这块,在来点评之前,还真没开发过这样的工具平台,这个算是我的第一个带web界面的工具。边Google边做,没想到不久还真的架起来了一个简易版本。

使用 Servlet + Jsp 进行开发;前端框架使用Bootstrap;前端数据使用jslt;数据库使用MySQL,服务器使用的公司的一台Beta环境Docker虚拟机;域名在ttt申请了公司内网域名,并开通北京上海两侧内网访问权限。

功能上基本都是要满足的。

界面上,虽然做不到惊艳吧,但是绝对不能丑,从小学画画的我对美是有追求的,功能满足,但是长得一副80年代的界面,我自己都会嫌弃去使用它。(同样能满足功能,谁不想用个更漂亮更有品味的东西呢?)所以界面上我还是话了一些时间去调整和设计。(后面熟练了就快多了)

所以现在Lego测试平台在内网中的域名是:http://lego.sankuai.com。
打开可以看到整个界面:

至少不丑吧。

 

3.用例维护

3.1 测试用例模板

看完4-用例篇之后,应该就能了解到,目前Lego平台支持Pigeon、Mapi 和 Http三种用例类型的,本质上都差不多,这里我那Pigeon用例做为例子进行详细讲解。

打开http://lego.sankuai.com/PigeonCase 页面,可以看到:

图中测试用例被分成了好几个部分,其中“参数化”、“前后置动作”、“检查点”这些名词已经在《4-用例篇》做过了解释,这里就不多阐述。

  • “参数化”、“前后置动作”、“检查点”支持多个同时使用,支持递归使用。
  • 在网站上,可以对测试用例进行编辑,更新,并且在线执行。
  • ID中输入用例编号回车会展示这条用例的详细信息。
  • 在已存在用例上点击【新建/复制】可以对现有用例进行复制。
  • “检查点”后都有使用说明的浮窗。
  • 在页面上就可以对用例进行维护,无需再下载code。
  • 由于都是依赖的base包,执行结果和每日ci跑的结果基本上是一毛一样的。
  • 在线执行,可以看到如下的测试用例执行log,可以从log中看到”参数”替换的过程,和“前后置动作”执行的过程。

 

3.2 批量生成Pigeon测试用例模板

这个功能很早就有了,适合想快速新增Pigeon测试用例的同学。

入口:[接口自动化] > [服务信息维护] > [批量生成Pigeon Service测试用例模版]

选择好团队和服务选择后,就可以批量生成测试用例了。

已存在的测试用例不会再生成,所以反复使用的话,可以对没有添加测试用例的接口进行用例模板的添加。
通过这个功能,可以实现Pigeon自动化测试用例的快速创建,快速达到接口覆盖,省去了很多参数数据的填写。

 

3.3 “参数化”、“前后置动作”、“检查点”

“参数化”、“前后置动作”、“检查点”都有独立的配置页面,支持web添加、修改和运行调试。

 

3.4 图表展示

由于测试用例的数据存储与数据库,所以可以很容易的对测试用例情况进行统计。

比如统计“服务下用例数”,“每天/每月/每季度新增用例数(团队维度/人的维度)”,“目前的接口覆盖率情况”等等用例数量层面的统计。

在“CI项目地址记录”中记录好自动化测试的Jenkins job地址,通过Jenkins Api定时获取结果数据,就能进行一些“成功率趋势图”的统计。

哪怕不是使用的Lego平台,只要Jenkins中有Result记录,同样能记录到。

同时还能将Jacoco数据一并爬取下来,展示成各种图标。

有了成功率数据,自然可以继续收集一波追踪记录,将失败原因划分成多种情况,可以统计出哪些失败用例是由于“服务问题”,那些失败用例是由于“数据问题”等原因造成的。

 

3.5 日常维护

简单介绍一下如何进行接口自动化日常维护吧。

由于每天会进行接口自动化的执行,所以早晨上班后,是可以看到一封执行结果的邮件的。

邮件上可看到测试结果,也有打开页面上详细测试报告的“链接”;

在详细报告中,可以看到用例执行的log,可以初步定是什么原因造成的,同时log中有一键跳转至Lego的该条用例维护页面;

修改数据,调试执行,没问题了,保存,记录失败原因;

明天再跑就会看到成功的结果,一般日常维护的时间可以保证在几分钟以内,

定位、修改、调试、更新一气呵成,这就是web版的好处。

 

3.6 …

还有很多功能,这里就不一一阐述了。

 

4. Lego-kit

最后一部分,Lego的工具包。

一些常用的功能,几乎都在这个jar包中实现。

并且如MaprReader这样的常用工具,在未使用Lego作为自动化的团队和一部分开发团队中,也得到了很好的应用。

 

5. 结束语

Lego测试平台一年多来,在没有正式推广的情况下,从只有4人使用,成了至少3个业务线40个团队的自动化测试工具,真是一段很神奇很难得的经历。

感谢这么多同学的使用,一个个实战中的需求也强化了Lego平台的功能。

感谢赵君一,丁媛等同事的支持和讨论;

通过这5篇文章,基本上是完成了一次小小的总结。

这是一个从0到1的过程;

但是这并不是结束;

接下来,就是要从1做到100分;

有很多新的想法和需求,已经在计划中;

期待我下一年做完后新的总结吧。

 

6. 一些问题的补充

在发布文章的过程中,有不少朋友发来消息问了很多问题,这里简单回答一下问的比较多的一些问题吧:

Q:是否打算开源?

A:目前没有打算开源,目前还是只是在公司内部使用,但是会在之后考虑一些通用的脚本进行开源,得抽掉自己公司部分的一些东西。

Q:Pigeon、Mapi是啥米?

A:点评内的一些接口类型

Q:大象?!

A:美团点评内部的聊天工具

 

 

 

发表评论

电子邮件地址不会被公开。