测试平台之接口自动化平台

前言

接口自动化，与UI自动化相比，其维护成本更低，结果校验更精确。目前，接口自动化无论是使用testng框架者还是使用Jmeter，都有一定的局限性，前者需要一定代码基础，且维护测试数据比较麻烦，后者简单易用，但共享性差一些。基于此，从前端选型、数据库表设计到实现方案设计与开发，我花费三个月时间完成了这个接口自动化测试平台。

1 简介

1.1 技术栈

• 后端：SpringBoot + Mybatis + mysql + redis
• 前端：jQuery + layui

关于前端，个人推荐没有前端基础的同学，可以从layui上手。后期视情况向vue靠拢，毕竟vue是目前主流的前端开发框架，在我们遇到问题时，如果使用和前端开发相同的框架，可以非常方便地向他们请教。

1.2 特点

• 极致简洁：页面简洁，交互方便，易于上手
• 数据管理：可视化数据管理，数据的添加与维护十分方便
• 分级设计：将数据按项目模块、接口、用例、测试集合划分，保证数据规范性和一致性，减少数据冗余
• 单点调试：支持接口测试用例的在线调用，输出响应结果、请求信息等详细信息
• 流程拼装：将多个已创建的测试用例拼接成测试集合，执行有一定业务逻辑的流程

2 详述

2.1 权限管理设计

经典的树状角色权限控制：

在角色控制之外，又单独为各个模块，比如接口自动化模块设计了组别权限：

新增数据与编辑数据相比，少了是否是本人数据的校验。

为组分配（增减）人员：

为组分配（增减）项目：

权限不足效果：

2.1 平台入口

登录页面使用Spring主题，清新雅致。不支持注册用户，只能由管理员添加用户。

平台集成了redis，token信息存储在redis中，并可在配置文件中自定义失效时间和加密规则：

redis:
    host: localhost
    port: 6379
    timeout: 10s
    lettuce:
      pool:
        min-idle: 0
        max-idle: 8
        max-active: 8
        max-wait: -1ms
    password:

token:
  expire:
    seconds: 72000
  jwtSecret: (XIAO:)_$^11244^%$_(WEI:)_@@++--(LAO:)_++++_.sds_(SHI:)

2.2 分级设计

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

2.2.1 项目管理

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

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

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

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

2.2.2 接口列表

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

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

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

2.2.3 用例管理

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

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

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

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

2.2.3.1 基本信息

基本信息，用例的描述性信息，自动读取。其中，所属平台、所属项目、所属模块等信息，读取自用例所属的模块，接口名称、接口路径等读取自用例所属的接口。

2.2.3.2 请求参数

请求参数，包括请求头和请求体两部分。

2.2.3.3 关联提取

这个功能是为后续【测试集合】准备的，当你准备把一个用例加入测试集合，且测试集合后续的接口的参数依赖该用例响应结果的值，就需要在关联处理做预处理。 比如一个登录用例，需要在响应结果中提取token并提供给后续接口使用，就可以按图中示例，添加一条关联提取规则：

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

2.2.3.4 结果断言

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

• 包含：响应结果包含预期值，即判定接口请求成功
• 等于：响应内容等于预期值，即判定接口请求成功
• JSON：通过路径表达式在响应结果中提取特定字段，该特定字段的值等于预期值，即判定接口请求成功

2.2.3.5 结果示例

结果示例是接口返回结果的示例：

2.2.4 测试集合

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

下面说明一下如何编辑一条测试集合：

1. 点击【编辑】按钮，将进入测试集合详情页，在该页面可以非常方便地增减用例、调整用例顺序。

1. 点击【+】按钮，进入用例添加页面：

1. 通过选定一系列筛选条件，【用例】行将展示所有符合筛选条件的用例，选择想要的用例后，点击【提交】即将该用例添加到测试集合的用例列表中。

1. 选择了用例后，回到测试集合详情页，用例顺序调整完毕后，点击【提交】按钮，将信息保存到数据库。同时，程序会自动生成【用例队列】（用例ID组成的队列）和【队列描述】（用例对应的接口名称组成的队列）。

新增一条测试集合与上述操作基本相同，不同的是，在【测试集合】页点击新增后，进入的集合详情页，只有一条示例用例：

测试集合支持【一键执行】，目前只支持单线程全部执行，后续考虑优化加入按项目执行和多线程执行。

2.2.5 测试结果

在【测试集合】页面选择执行某条测试集合后，程序将读取其对应的用例队列，并依次执行每个用例，最终生成一条测试集合的测试结果，并持久化保存在数据库中。

点击【详情】按钮，进入测试结果详情页，查看某条测试结果的详情：

双击某行，弹出该行对应的响应结果：

3 难点与待优化列表

3.1 关联的实现

关联在【用例管理】的【关联提取】已有简单阐述，这里详述一下其实现方案：

• 首先，当一条测试集合被执行时，在栈内存中开辟一个Map或JSONObject，我称其为关联池。
• 执行每条用例时，读取其【关联提取】数据，如果有记录，解析该记录并按提取规则去用例的响应结果中提取相应内容（提取失败则取其缺省值），并将该内容put到关联池中。
• 执行每条用例时，如果用例的某个参数的值是 ${param} 格式，意味这个参数值是引用值，则将"param"解析出来，并到关联池中以"param"为key执行get操作。
• 基于这种设计机制，我们还可以实现下面的场景：第一个用例的参数A的值是2001，后面用例涉及到参数A的值都想跟第一个用例保持一致，如果每个用例都写成固定值，那么一旦修改将是很麻烦的事。那么，我们可以在关联提取中添加一行，路径故意写错，缺省值写为‘2001’，当该用例执行时，关联提取失败，缺省值‘2001’就被put到了关联池中，后面的用例引用该值即可。
• 测试集合执行完成后，关联池被销毁。

实现思路的示意图如下：

3.2 待优化列表

• 定时任务：新增定时任务管理页面，支持定时任务可视化编辑。
• 邮件发送：将测试结果发送给相关人，目前测试结果以什么格式（纯文本还是html）发送尚未选定。
• 多线程：测试集合支持按项目执行，并开启线程池，加快执行效率。
• 前置条件：用例是否执行依赖于前置条件是否被满足。
• 重试策略：用例执行失败自动重试n次（n可配置）。
• 请求参数：请求参数支持JSON体。