前言

好久没在社区发表过文章了，今天的目的是来取经的。

差异性

区别于Http 接口测试框架 -- 回归验证

• 不只是回归验证
• 更详尽的用例覆盖度
• 属于单测范畴，能重复执行
  • Http 接口测试框架的重复执行是不太理想的（传参固定，没有清理数据操作）
  • 举例：第一次拉黑某用户是可以拉黑成功的，再次执行拉黑某用户就失败了，因为已经被拉黑过
  • 本版本的设计初衷是解耦的
  • 举例：拉黑过某用户，断言后，会清理数据，就是会取消拉黑，下次执行就能拉黑成功
• 更优秀的配置管理

技术层

• IDE：IntelliJ IDEA

• 编译：maven

• 请求：rxjava + retrofit

• 数据库：SQL Server（与后端同步）

• 断言：TestNG + 自定义

• 执行：TestNG

• 报告：ExtentReports

项目结构

请求设计

接口层设计

Api

• Project A
  • Module A
    • Interface A
    • Interface B
    • Interface C
  • Module B
  • Module C
• Project B
• Project C
• Type（模块包）
  • 模块 A（里面是该模块下的所有接口请求）
  • 模块 B

测试集设计

Suite

• Module A Suite
• Module B Suite
• Group A Suite
• Group B Suite
• Other A Suite
• Other B Suite

用例层设计

• 同接口层结构一致（除模块包）

偷懒过程一

Java 接口测试不同于 Python 接口测试，Java 需要一个实体类来映射接口返回结构，所以需要一个实体类。

• 起初是人工编写，写了 2 个后受不了了，工作量太大

• 然后装了个 GsonFormat，速度有些许提升，写了一个模块后，又受不了

• 改进：

  • 第一步：Python 爬取接口文档，生成接口实体类（含请求参数，不含实体结构，原因是文档的结构非最新，无奈）
  • 第二步：框架层增加 JavaBean 生成器，由BeanPoet直接生成实体类输出到output文件夹
  • 用例打上注解就能生成实体类

  public class GetTokenCase {
  
      @Test
      @JavaBean
      public void testGetToken() {
      }
  }
  

  ​

偷懒过程二

请求实体的封装又是一个工作量巨大的地方

• 起初是人工写方法，一个参数一个参数的写，简直要命

• 然后利用 IDE 的Live Templates自定义一些方法

  • 例如输入 pstm 就能产出下面一堆代码，只需操作具体的参数即可

public static <T> T method(Class<T> clazz) {
    Map<String, Object> params = new HashMap<>();
    params.put(, );

    String name = NameUtils.toUpperCaseForFirst(NameUtils.getMethodName());
    String path = TYPE + "/" + name;
    return RequestEmitter.emit(clazz, params, path);
}

• 改进：

  • 利用 Python 爬取接口文档的同时，封装好调用方法，直接输出到文件
  • 改进后的样子

  public static <T> T getDeliveryAddressList(int start, Class<T> clazz) {
          Map<String, Object> params = new HashMap<>();
          params.put(GetDeliveryAddressListEntity.START, start);
  
          String name = NameUtils.toUpperCaseForFirst(NameUtils.getMethodName());
          String path = TYPE + "/" + name;
          return RequestEmitter.emit(clazz, params, path);
      }
  

  ​

用例编写

由于各种封装，用例的编写变得异常简单，只需关注具体的业务逻辑即可

一种巧妙的设计

必需遵循规则才不会出错

• 一个接口：https://api.douban.com/v2/movie/top250?start=0&count=10

• base url：https://api.douban.com/v2

• path url：movie/top250

• 模块：movie

• 接口：top250

• 设计：

报告

总结

• 实体类已经自动化生成

• 请求封装已经自动化生成

• DB 层还未实现

• 用例的设计需要取经

​

取经

• 对于接口用例的设计
  • 数据驱动（一个接口相同的传参，不同的测试数据，但是返回的结果结构不一定是一样的，不太好验证？）
  • 精确设计（能自定义各种断言，但是需要设计众多用例？传参一样，但是数据不一样，返回结构有差异，除非断言不验证那么细？）
• 数据的准备方式
  • 测试录入（解耦，需要操作数据库，但是线上监控怎么玩？）
  • 业务依赖（一个接口的失败，可能影响其他接口的测试结果）
• 最重要的还是接口用例的设计
• 最重要的还是接口用例的设计
• 最重要的还是接口用例的设计