51Testing软件测试论坛

标题: 接口业务测试 -- Java 版 [打印本页]

---

作者: 草帽路飞UU    时间: 2017-6-15 09:32
标题: 接口业务测试 -- Java 版


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

​
取经

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

---

作者: 乐哈哈yoyo    时间: 2017-6-15 09:41
赞一个

---

作者: 草帽路飞UU    时间: 2017-6-15 09:44

乐哈哈yoyo 发表于 2017-6-15 09:41
赞一个

---

作者: 巴黎的灯光下    时间: 2017-6-15 10:06
666

---

作者: 草帽路飞UU    时间: 2017-6-15 10:09

巴黎的灯光下 发表于 2017-6-15 10:06
666

---

作者: 岛屿soliloquy    时间: 2017-6-16 12:00
表示看的不是很懂。
膜拜版主。

---

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)

Powered by Discuz! X3.2