接口测试 基于 Springboot+layui 实现接口自动化平台
前言
一次偶然的机会来到这里，有种恍然大悟的感觉：原来大家都在这里！我说在 CSDN 上很少看到测试相关的文章呢。翻看了几篇，各位谈笑间，水平尽显——进这里就像回到家一样，进了里面去个个都是人才，说话又好听，超喜欢在里面。
我本人是 19 年 6 月份开始在 CSDN 写些博文的，这里也顺势推荐一波，欢迎大家关注、交流。博客地址奉上：https://blog.csdn.net/mu_wind。
发现测试里走 Java 路线的真是少之又少，希望多遇到几个同道中人吧。
言归正传，今天来跟大家分享一个自己的作品 -- 基于Springboot+layui实现接口自动化平台，如果感兴趣的人多，会考虑开源。回顾这段岁月，甘苦自知。既有遇到难点一筹莫展、食之无味的困窘，也有解决难题调试成功的欣喜，堪称五味杂陈。人言奋斗的岁月最充实，果然如此。
闲言几句：读了几篇文章，颇有几番质疑技术的言论，在我看来，技术是一把刀，越锋利越好，如果这把刀发挥不了功效，那是拿刀的人出了问题，而非刀本身。当然，技术一定要结合业务，否则就成了无柄之刃，再锋利也是徒劳。
好，正式开始。平台采用的技术栈有：
- 后端：Springboot、mysql、redis
- 前端：jQuery、layui
平台数据采用分层设计，即将接口自动化所需的数据分为【项目管理】、【接口列表】、【用例管理】、【测试集合】、【测试结果】五个部分。如下图所示：
平台入口，颜值即正义，尽量弄得漂亮一点，也让人有使用的欲望。
1 项目管理
项目管理，定义了公司系统的基本框架。以新浪新闻为例，我将做如下分割：
- 平台：新浪新闻
- 项目：体育
- 模块：西甲
- IP 地址：略
项目模块层，有以下规范和特点：
- 项目管理页面决定了每个接口的归属，当我们新增接口时，必须创建在已有模块下，而不能随心所欲地添加。因为平台使用人众多，如果不做此约束，数据将会十分混乱。
- 通常情况下，每个项目对应着自己的 IP 地址。这个平台中，每个模块对应着一个 IP 地址，还是有一些数据冗余，但如果为了消除数据冗余而再增加一层，就不是三表关联而是四表关联了，开发难度倍增，使用起来也略显繁琐。
- 每个模块定义了 IP 地址后，该模块下的接口将直接继承，不需要再单独为接口定义 IP 地址了。
2 接口列表
当项目模块创建后，就可以在该模块下添加接口了。
接口层有以下规范和特点：
- 这个页面定义了一个接口的基本信息，包括路径、请求方法、参数类型等，但不会定义具体的参数以及其他信息，这些信息留到用例页去定义。
- 每个接口只能有一条记录，新增时根据接口路径进行判重，以便进一步增强数据规范性，防止出现明明是一个接口，但接口名称不一样的情况。
- 新增接口时，平台、项目、模块皆为选择项（可选择的数据来源于【项目管理】），而不能自行填入。
3 用例管理
用例管理是对接口的进一步描述，是最核心的部分，也是开发难度最大的一个模块。用例可以直接调用调试：
用例层具有以下规范和特点：
- 用例依赖于接口而存在，只有在接口列表页创建了某个接口后，才能在此页面创建该接口的用例，用例将自动继承所属接口和模块的属性，比如 IP 地址和路径等。
- 一个接口可以有多个用例，用例之间参数值不同。
- 用例类型分为标准用例、正常用例、异常用例，所谓标准用例是指该用例的参数等信息都是能确保用例能正常执行并获取正常响应结果的用例，每个接口下只能有一个标准用例，当接口下创建了标准用例后，再次创建用例时，直接复制其参数信息等数据，极大增加创建用例的便利性。
- 操作栏点击【执行】按钮后，将发起一次接口请求，参数为该用例的数据。
- 点击【编辑】可以修改用例的基本信息。
- 点击【详情】，进入用例详情页。
用例详情页有以下几大部分：
1、基本信息：用例的描述性信息，自动读取。其中，所属平台、所属项目、所属模块等信息，读取自用例所属的模块，接口名称、接口路径等读取自用例所属的接口。
2、请求参数，包括请求头和请求体两部分。
3、关联提取：这个功能是为后续【测试集合】准备的，当你准备把一个用例加入测试集合，且测试集合后续的接口的参数依赖该用例响应结果的值，就需要在关联处理做预处理。
比如一个登录用例，需要在响应结果中提取 token 并提供给后续接口使用，就可以按图中示例，添加一条关联提取规则：
- 变量名：提取到的信息暂存到内存中时对应的变量名
- 路径表达式：需要提取的内容对应的路径，其书写格式与使用规则与 Jmeter 的【JSON Extractor】完全一致。
- 缺省值：当提取预期内容失败时，给变量名赋予的值。
4、结果断言：目前包括常规断言和 Beanshell 断言两种形式，其中常规断言包括：包含、相等、JSON 三种方式（已经能覆盖大多数应用场景，后续可以继续丰富）
5、结果示例是接口返回结果的示例：
4 测试集合
测试集合可以说是这个接口自动化平台的意义之所在。在接口自动化中，单接口调用参考价值有限，多个接口按照业务逻辑组成一条流程，才是接口自动化意义所在。
当一系列接口用例创建完成后，在【测试集合】页面可以按照业务逻辑将它们组装起来，形成一个任务队列。
下面说明一下如何编辑一条测试集合：
- 点击【编辑】按钮，将进入测试集合详情页，在该页面可以非常方便地增减用例、调整用例顺序。
- 点击【+】按钮，进入用例添加页面：
- 通过选定一系列筛选条件，【用例】行将展示所有符合筛选条件的用例，选择想要的用例后，点击【提交】即将该用例添加到测试集合的用例列表中。
- 选择了用例后，回到测试集合详情页，用例顺序调整完毕后，点击【提交】按钮，将信息保存到数据库。同时，程序会自动生成【用例队列】（用例 ID 组成的队列）和【队列描述】（用例对应的接口名称组成的队列）。
5 测试结果
在【测试集合】页面选择执行某条测试集合后，程序将读取其对应的用例队列，并依次执行每个用例，最终生成一条测试集合的测试结果，并持久化保存在数据库中。
点击【详情】按钮，进入测试结果详情页，查看某条测试结果的详情：
双击某行，弹出该行对应的响应结果：
接口测试平台功能大体上就以上，还有很多需要优化的地方，比如
- 定时任务，将以项目或测试集合为单位布置定时任务执行。
- 结果报告，这个功能常有的华丽丽的测试报告，个人觉得华大于实，有精力再搞搞吧。
- 交互优化，测试数据页面左侧增加树状列表，方便数据查找。
哎
牛
Javase 基础不牢固，我先插个眼，后续来学习
比较感兴趣在实际业务中落地的情况，可以分享下这方面的信息么？
顺便想问问楼主 Java 系的学习路线，俺以前培训学过 JavaSE、然后 Java 系的 UI 自动化、接口自动化不过忘完了。。。
功能好完整……
陈恒捷
回复
这个平台呢，目前主要用在接口的全量回归上，优缺点都有。
先说说优点吧，
1、测试团队全体成员增删改查接口的测试数据非常方便，就像操作 excel 一样简单，而且提供了标准用例的功能，每个接口只要手动创建一个标准用例，后续再添加用例自动写入相关数据。
2、只要用例都准备好，测试集合的拼装非常便利，关联功能完全满足需求，而且成员间用例可复用，实现了数据共享
至于缺点呢，主要体现在无法支持个性化的需求，比如：
1、对结果进行复杂校验，比如对接口响应结果的逻辑运算校验和数据库校验等。
2、测试的场景做不到 JMeter 那么复杂，比如各种循环控制器、IF 控制器等。
通用性和个性化本来就难以调和，我思考良多，也没有好的办法。后续的思路是，将复杂的测试流程做成可视化的任务调用，但这样复杂度就高了，数据修改也很不方便了。
柒
回复
学习路线的话，可以关注我的 CSDN 博客照着动手做，博客地址在文章开头。我的建议是，直接上手做点小东西，倒逼式学习，切忌看书看视频按部就班的学习，那样的话没有阶段性成果刺激，很难坚持下去。
平台一个个，没见过几个可以落地的。
插眼
蛮不错的，值得期待，等待开源
还是那句话，平台是武器，能不能落地在于公司需求力度。而且，我初衷只是分享，可以看我 CSDN 博客，在货真价实地写文章。
测试适合 python；运维适合 golang；开发适合 java；先学 python 和 go 吧；后面要和开发部门做一些对接的东西在玩 java 不迟；python 很强大了；足够硬付前俩年的测试生涯了；一门语言会了后面学起来一两个月的事情；
时间充足还是 go python java 都学了吧
springboot+layui 吸引到我了，这两个都用过，很方便。。楼主说的缺点：无法支持个性化需求，这点有计划实施解决么。
对于接口自动化，还是需要很多查询数据库进行校验的操作。
后台用例执行，使用什么方式执行的？直接填充成 HttpClient 发起请求执行用例么？
有没有人有想法，弄一个在线接口自动化编写 (或者生成接口自动化脚本) 的方式？ 类似在线编辑器，编辑 python 代码，执行用例在线看 console 和报告的方式？
MeterSphere 小助手
回复
感谢！这个工具看着有点复杂，我是想做那种把 pycharm 搬到 web 的接口自动化平台，可以看到整个文件目录结构，既可以线上跑，又可以线下导入 pycharm 跑。
请问楼主，你得博文可以完全实现你工作中项目的功能吗？
我就问一个问题，用例关联怎么做的，比如一个请求依赖上一个请求的响应的结果中的某些字段
楼主牛 B，现在用 java 的测试不多，还会 ssm 的就更不多了。对结果进行复杂校验，可以用 jsonpath 来实现，尤其是返回数据比较复杂的那种，还有就是接口依赖、token 等的问题，你这好像没有提到，都可以用 jsonpath 的方式来处理，至于数据库校验的校验，个人认为在接口层可以不查 DB，那些交给单元测试来处理，如果真的要检验插入的数据，也可以调查询的接口来完成，查询接口能查出来，就说明 DB 就写入了数据。各种循环控制器、IF 控制器等，这些嘛，可以另起一个 class 来处理这样的接口，并不是每个接口都有这么复杂的业务。
楼主的这个项目，有开源的计划吗，学习下。
我就问一句话：开源么？
Ethon
回复
JSONPath 断言是支持的，你可再仔细看用例详情那部分，是可以选择 JSON 断言，通过填写路径表达式和预期值来做 JSON 校验的。我所说的复杂校验是指业务逻辑的校验，关于这方面，也集成了 Beanshell 断言，但并不是很好调试。不过你说得很对，这些校验也不适合放在这个平台里，而是要在录入平台前就保证了接口业务逻辑的正确性。
Draymonder
回复
关联的话，借鉴了 JMeter 的处理方式，
以登录为例，先从登录接口响应结果中提取后续接口需要关联的值，即 token，并保存：
在同一个测试集合里，需要使用这个 token 的，以 ${token}的方式即可引用。
这种方式是动态关联，指关联变量在一个测试集合里生成和使用，测试集合跑完后就失效。还可以考虑，设置专门的全局变量，这个我还没做，不过实现起来很容易。
Ethon
回复
接口依赖和 token 处理，借鉴了 JMeter 的处理方式，
以登录为例，先从登录接口响应结果中提取后续接口需要关联的值，即 token，并保存：
在同一个测试集合里，需要使用这个 token 的，以 ${token}的方式即可引用。
这种方式是动态关联，指关联变量在一个测试集合里生成和使用，测试集合跑完后就失效。还可以考虑，设置专门的全局变量，这个我还没做，不过实现起来很容易。
gitchat 发的一个文跟你很像是你吗
感谢楼主用心写的文章，我也是一名测试，走的 java 路线，想要开发平台，看到你这篇文章确实给我很多启发，非常感谢。也希望楼主能够开源，让我学习，测试是一条很长很长的路，但是在长的路，我们慢慢走就是了，用心的人总是不会被辜负，愿所有的付出最后都值得。
很赞
看这个报错信息 是券商呀？
咳。。。 见多这类平台了，实际业务没法落地，特别是复杂场景，又有上游，又得多环境支持。
5、6 年前玩这套把自己玩死了，而后别人再问我 API\RPC 自动化测试最佳实践，都甩 3 个字：写代码。
想问一下各位大佬，像接口自动化方面如何落地呢？
哎，这类平台实际落地效果一言难尽，开发起来耗费精力，使用起来束手束脚
什么时候开源
LTV
回复
接口并发问题解决不了，另外控制器其实是可以做的，参考 jmeter 的处理，控制器就当成一个集合，里面放测试用例，根据控制器类型去处理这部分用例代码
https://github.com/metersphere/metersphere
这个开源的哈，可以看下这个~
楼主，计划什么时候开源呢，期待中。。。
