[转]徒手撸自动化平台

徒手撸自动化平台

TesterHome 今天

前言

一次偶然的机会来到这里，有种恍然大悟的感觉：原来大家都在这里！我说在 CSDN 上很少看到测试相关的文章呢。翻看了几篇，各位谈笑间，水平尽显——进这里就像回到家一样，进了里面去个个都是人才，说话又好听，超喜欢在里面。

我本人是 19 年 6 月份开始在 CSDN 写些博文的，这里也顺势推荐一波，欢迎大家关注、交流。博客地址奉上：https://blog.csdn.net/mu_wind。

发现测试里走 Java 路线的真是少之又少，希望多遇到几个同道中人吧。

言归正传，今天来跟大家分享一个自己的作品--基于Springboot+layui实现接口自动化平台，「如果感兴趣的人多，会考虑开源」。回顾这段岁月，甘苦自知。既有遇到难点一筹莫展、食之无味的困窘，也有解决难题调试成功的欣喜，堪称五味杂陈。人言奋斗的岁月最充实，果然如此。

❝

闲言几句：读了几篇文章，颇有几番质疑技术的言论，在我看来，技术是一把刀，越锋利越好，如果这把刀发挥不了功效，那是拿刀的人出了问题，而非刀本身。当然，技术一定要结合业务，否则就成了无柄之刃，再锋利也是徒劳。

❞

好，正式开始。平台采用的技术栈有：

• 后端：Springboot、mysql、redis
• 前端：jQuery、layui

平台数据采用分层设计，即将接口自动化所需的数据分为【项目管理】、【接口列表】、【用例管理】、【测试集合】、【测试结果】五个部分。如下图所示：

img

平台入口，颜值即正义，尽量弄得漂亮一点，也让人有使用的欲望。

 

img

1 项目管理

项目管理，定义了公司系统的基本框架。以新浪新闻为例，我将做如下分割：

• 平台：新浪新闻
• 项目：体育
• 模块：西甲
• IP 地址：略

img

项目模块层，有以下规范和特点：

• 项目管理页面决定了每个接口的归属，当我们新增接口时，必须创建在已有模块下，而不能随心所欲地添加。因为平台使用人众多，如果不做此约束，数据将会十分混乱。
• 通常情况下，每个项目对应着自己的 IP 地址。这个平台中，每个模块对应着一个 IP 地址，还是有一些数据冗余，但如果为了消除数据冗余而再增加一层，就不是三表关联而是四表关联了，开发难度倍增，使用起来也略显繁琐。
• 每个模块定义了 IP 地址后，该模块下的接口将直接继承，不需要再单独为接口定义 IP 地址了。

2 接口列表

当项目模块创建后，就可以在该模块下添加接口了。

img

接口层有以下规范和特点：

• 这个页面定义了一个接口的基本信息，包括路径、请求方法、参数类型等，但不会定义具体的参数以及其他信息，这些信息留到用例页去定义。
• 每个接口只能有一条记录，新增时根据接口路径进行判重，以便进一步增强数据规范性，防止出现明明是一个接口，但接口名称不一样的情况。
• 新增接口时，平台、项目、模块皆为选择项（可选择的数据来源于【项目管理】），而不能自行填入。

img

3 用例管理

用例管理是对接口的进一步描述，是最核心的部分，也是开发难度最大的一个模块。用例可以直接调用调试：

用例层具有以下规范和特点：

• 用例依赖于接口而存在，只有在接口列表页创建了某个接口后，才能在此页面创建该接口的用例，用例将自动继承所属接口和模块的属性，比如 IP 地址和路径等。
• 一个接口可以有多个用例，用例之间参数值不同。
• 用例类型分为标准用例、正常用例、异常用例，所谓标准用例是指该用例的参数等信息都是能确保用例能正常执行并获取正常响应结果的用例，每个接口下只能有一个标准用例，「当接口下创建了标准用例后，再次创建用例时，直接复制其参数信息等数据，极大增加创建用例的便利性」。
• 操作栏点击【执行】按钮后，将发起一次接口请求，参数为该用例的数据。
• 点击【编辑】可以修改用例的基本信息。
• 点击【详情】，进入用例详情页。

用例详情页有以下几大部分：

1、基本信息：用例的描述性信息，自动读取。其中，所属平台、所属项目、所属模块等信息，读取自用例所属的模块，接口名称、接口路径等读取自用例所属的接口。2、请求参数，包括请求头和请求体两部分。3、关联提取：这个功能是为后续【测试集合】准备的，当你准备把一个用例加入测试集合，且测试集合后续的接口的参数依赖该用例响应结果的值，就需要在关联处理做预处理。比如一个登录用例，需要在响应结果中提取 token 并提供给后续接口使用，就可以按图中示例，添加一条关联提取规则：

• 变量名：提取到的信息暂存到内存中时对应的变量名
• 路径表达式：需要提取的内容对应的路径，其书写格式与使用规则与 Jmeter 的【JSON Extractor】完全一致。
• 缺省值：当提取预期内容失败时，给变量名赋予的值。

4、结果断言：目前包括常规断言和 Beanshell 断言两种形式，其中常规断言包括：包含、相等、JSON 三种方式（已经能覆盖大多数应用场景，后续可以继续丰富）5、结果示例是接口返回结果的示例：

4 测试集合

测试集合可以说是这个接口自动化平台的意义之所在。在接口自动化中，单接口调用参考价值有限，多个接口按照业务逻辑组成一条流程，才是接口自动化意义所在。当一系列接口用例创建完成后，在【测试集合】页面可以按照业务逻辑将它们组装起来，形成一个任务队列。下面说明一下如何编辑一条测试集合：

1. 点击【编辑】按钮，将进入测试集合详情页，在该页面可以非常方便地增减用例、调整用例顺序。
2. 点击【+】按钮，进入用例添加页面：
3. 通过选定一系列筛选条件，【用例】行将展示所有符合筛选条件的用例，选择想要的用例后，点击【提交】即将该用例添加到测试集合的用例列表中。
4. 选择了用例后，回到测试集合详情页，用例顺序调整完毕后，点击【提交】按钮，将信息保存到数据库。同时，程序会自动生成【用例队列】（用例 ID 组成的队列）和【队列描述】（用例对应的接口名称组成的队列）。

5 测试结果

在【测试集合】页面选择执行某条测试集合后，程序将读取其对应的用例队列，并依次执行每个用例，最终生成一条测试集合的测试结果，并持久化保存在数据库中。点击【详情】按钮，进入测试结果详情页，查看某条测试结果的详情：双击某行，弹出该行对应的响应结果：

接口测试平台功能大体上就以上，还有很多需要优化的地方，比如

• 定时任务，将以项目或测试集合为单位布置定时任务执行。
• 结果报告，这个功能常有的华丽丽的测试报告，个人觉得华大于实，有精力再搞搞吧。
• 交互优化，测试数据页面左侧增加树状列表，方便数据查找。