接口业务测试 -- Java 版
本帖最后由 草帽路飞UU 于 2017-6-15 09:36 编辑前言好久没在社区发表过文章了，今天的目的是来取经的。
差异性区别于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层还未实现
[*]用例的设计需要取经
取经
[*]对于接口用例的设计
[*]数据驱动（一个接口相同的传参，不同的测试数据，但是返回的结果结构不一定是一样的，不太好验证？）
[*]精确设计（能自定义各种断言，但是需要设计众多用例？传参一样，但是数据不一样，返回结构有差异，除非断言不验证那么细？）
[*]数据的准备方式
[*]测试录入（解耦，需要操作数据库，但是线上监控怎么玩？）
[*]业务依赖（一个接口的失败，可能影响其他接口的测试结果）
[*]最重要的还是接口用例的设计
[*]最重要的还是接口用例的设计
[*]最重要的还是接口用例的设计
赞一个:victory: 乐哈哈yoyo 发表于 2017-6-15 09:41
赞一个
:lol 666 巴黎的灯光下 发表于 2017-6-15 10:06
666
:victory: 表示看的不是很懂。
膜拜版主。:handshake
页:
[1]
