Lego测试平台05-网站篇

本章开始介绍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.********.com。
打开可以看到整个界面：

至少不丑吧。

 

3.用例维护

3.1 测试用例模板

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

打开http://lego.********.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：美团点评内部的聊天工具