接口业务测试 -- Java 版

草帽路飞UU · 发表于 2017-6-15 09:32:39

本帖最后由草帽路飞UU 于 2017-6-15 09:36 编辑

前言好久没在社区发表过文章了，今天的目的是来取经的。
差异性区别于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层还未实现
用例的设计需要取经

取经

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