芭比哇玩123 发表于 2017-6-1 15:05:08

接口业务测试 -- Java 版

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

[*]不只是回归验证
[*]更详尽的用例覆盖度
[*]属于单测范畴，能重复执行

[*]Http 接口测试框架的重复执行是不太理想的（传参固定，没有清理数据操作）
[*]举例：第一次拉黑某用户是可以拉黑成功的，再次执行拉黑某用户就失败了，因为已经被拉黑过
[*]本版本的设计初衷是解耦的
[*]举例：拉黑过某用户，断言后，会清理数据，就是会取消拉黑，下次执行就能拉黑成功
[*]更优秀的配置管理
技术层
[*]IDE：IntelliJ IDEA

[*]编译：maven

[*]请求：rxjava + retrofit

[*]数据库：SQL Server（与后端同步）

[*]断言：TestNG + 自定义

[*]执行：TestNG

[*]报告：ExtentReports

项目结构
https://testerhome.com/uploads/photo/2017/8757d768-5f0a-4742-befc-9c5a7e428f74.png%21large


请求设计

https://testerhome.com/uploads/photo/2017/67bd0f6e-acc8-4ea4-a777-882597e0e591.png%21large


接口层设计
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://testerhome.com/uploads/photo/2017/ceba8f01-04ad-43b2-b00c-d09ef58c0bac.png%21large


一种巧妙的设计必需遵循规则才不会出错

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

[*]base url：https://api.douban.com/v2

[*]path url：movie/top250

[*]模块：movie

[*]接口：top250

[*]设计：


https://testerhome.com/uploads/photo/2017/bfb2f30b-0834-4f7f-930b-e51b31d483a8.png%21large


报告
https://testerhome.com/uploads/photo/2017/1f727ed3-67c1-4b34-ac0f-554b69b81913.png


总结
[*]实体类已经自动化生成

[*]请求封装已经自动化生成

[*]DB层还未实现

[*]用例的设计需要取经

​
取经
[*]对于接口用例的设计

[*]数据驱动（一个接口相同的传参，不同的测试数据，但是返回的结果结构不一定是一样的，不太好验证？）
[*]精确设计（能自定义各种断言，但是需要设计众多用例？传参一样，但是数据不一样，返回结构有差异，除非断言不验证那么细？）
[*]数据的准备方式

[*]测试录入（解耦，需要操作数据库，但是线上监控怎么玩？）
[*]业务依赖（一个接口的失败，可能影响其他接口的测试结果）
[*]最重要的还是接口用例的设计
[*]最重要的还是接口用例的设计
[*]最重要的还是接口用例的设计

小皮球的故事 发表于 2017-6-1 15:12:15

很详细！

芭比哇玩123 发表于 2017-6-1 15:13:01

小皮球的故事 发表于 2017-6-1 15:12
很详细！

:victory:

测试就是来开荒 发表于 2017-6-1 15:15:15

赞一个

芭比哇玩123 发表于 2017-6-1 15:15:53

测试就是来开荒 发表于 2017-6-1 15:15
赞一个

:victory:

清晨一缕阳光 发表于 2017-6-1 15:46:58

:victory:支持分享
页: [1]
查看完整版本: 接口业务测试 -- Java 版