接口测试 接口业务测试 -- Java 版

heyniu · 发布于 2017年06月01日 · 最后由 heyniu 回复于 2017年07月21日 · 5457 次阅读
本帖已被设为精华帖!

前言

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

差异性

区别于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);
        }
    

用例编写

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

一种巧妙的设计

必需遵循规则才不会出错

报告

总结

  • 实体类已经自动化生成

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

  • DB层还未实现

  • 用例的设计需要取经

取经

  • 对于接口用例的设计
    • 数据驱动(一个接口相同的传参,不同的测试数据,但是返回的结果结构不一定是一样的,不太好验证?)
    • 精确设计(能自定义各种断言,但是需要设计众多用例?传参一样,但是数据不一样,返回结构有差异,除非断言不验证那么细?)
  • 数据的准备方式
    • 测试录入(解耦,需要操作数据库,但是线上监控怎么玩?)
    • 业务依赖(一个接口的失败,可能影响其他接口的测试结果)
  • 最重要的还是接口用例的设计
  • 最重要的还是接口用例的设计
  • 最重要的还是接口用例的设计
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 32 条回复
6022

好帖子必须顶一个

6436

开源吗?

7866

正如差异性说的,取经处 考虑过于复杂,是不是违背了初衷

96

哈哈。。。懒人推动世界,加油,小伙,我们都看好你!!!!😋 😋 😋 😋 😋

A5a164

求GitHub地址

104 seveniruby 将本帖设为了精华贴 06月01日 14:08
A24049

楼主开源吗,还有就是为什么不采用reportng报表形式呢

6504

接口加密,场景设计,关联这些地方怎么处理的?

9591
heyniu · #9 · 2017年06月01日 作者
6504lose 回复

接口加密

  • 因为保密问题,源码暂时还不能发出来,所以看不到加密的处理
  • 大概说下:每次请求的token都是重新计算的,可以参考之前的http接口测试框架

场景设计

上面我也说了我的思路,所以这个就是我想得到的答案

关联

初衷是解耦的,所以没有任何关联
任何接口都可以单独运行,不依赖其他接口

9591
heyniu · #10 · 2017年06月01日 作者
A24049yinquanwang 回复

因为那个颜值不够,就这么简单

9591
heyniu · #11 · 2017年06月01日 作者
A5a164summer2 回复

暂时还发不了

9591
heyniu · #12 · 2017年06月01日 作者

暂时还发不了哦

9591
heyniu · #13 · 2017年06月01日 作者
7866rubyvirus 回复

你有什么好的建议吗

9591
heyniu · #14 · 2017年06月01日 作者
6022qg__gq 回复

赶紧下班回家,老板都给你放假了

9591
heyniu · #15 · 2017年06月01日 作者
32sycing 回复

懒成一头猪了

6504
9591heyniu 回复

恩,我最近也在弄这块,场景设计我基于PICT二次开发,加密规则封装一个公用类

6233

感觉搞复杂了....

9591
heyniu · #18 · 2017年06月02日 作者
6233dongdong 回复

那块复杂了,我参考参考

3652
9591heyniu 回复

请问下关于重复执行请问例子中“取消拉黑” 是通过另一个取消拉黑的接口实现还是其他比如清理数据库实现的;
有时候会发现一些接口流程很复杂,干净的清理数据库几乎不可能,有些又没有反向接口(其实下次运行也依赖了上次的结果了),在想如果有独立的测试环境如果能实现每次自动化前能回退到测试前可能会更好。

Ae4f4b

reset Assured 感觉能省你不少事情

2113

说实话看完,并没有感受到亮点在哪,可能是每个公司业务不太一样,感觉没有说清楚怎样能让使用者能更高效的编写接口自动化用例,说白了不知道用你这样做跟用普通的工具框架优势在哪~
爬接口 文档生成测试用例?

另外接口用例设计的问题:
主要还是要上手快,要在批量修改新增的场景上面想想办法。
还有就是考虑用例的管理和调试怎么样方便,复用性高等等
数据传递的话可以考虑自己写一个 数据工厂。

另外我感觉应该是把复杂的东西简单化 而不是简单的东西上手难!

9591
3652cs_awater 回复

非线上环境,应该可以通过操作数据库来实现
线上环境,不管就好了吧,我目前还不知道怎么玩

9591
heyniu · #23 · 2017年06月05日 作者
Ae4f4bbaizhi 回复

能麻烦举例一下吗

9591
heyniu · #24 · 2017年06月05日 作者
2113testly 回复

亮点这东西不纠结了,可能我没表达清楚,可能因为没源码的缘故,初衷就是解耦。
另外用例的编写是这样的,个人认为够简单了

A491f2
6504lose 回复

楼主,我在 Appium 开源框架 appium+python (二) 支持多设备并行 + 性能监控 +webserver 监控 crash日志 这篇帖子里看到了你写的监控闪退日子的jar包源码,但是下载源码后,发现部分模块里没写代码啊。比如
跟你帖子上贴出来的这个模块一比,发现主要功能的代码都没有啊,能不能重新更新下啊

另外你说
想问下这个libs是appium+python自动化工程下的libs吗?能不能截图说明下,我只看到Lib文件夹

6504
A491f2jinyang.deng 回复

crashhandler目录下,你把整个项目下载下来就知道了

A491f2
6504lose 回复

我是想问,下载你的源码并更改host、port后打包成jar文件,那么打包后的这个jar文件要怎么利用到appium+python实现多设备并行的框架里才能捕获闪退日志,该放到哪里用;
我是初学。看了几天了,把你写的appium+python实现多设备并行的代码理解的差不多了,就是这个抓取日志搞不懂。

求lose大神详细指导下,谢谢

A491f2
6504lose 回复

又认真看了你在那篇帖子里的各种回复,总结了一下,我现在是这样理解的,你看对不对;
把CrashHandler打包成jar,然后把这个jar引用到需要测试的apk源码的libs文件下。再去测试这个包含了CrashHandler.jar的app;如果app闪退就会发送日志到自动化框架的web_server;然后自动化框架才能拿到日志对日志进行处理是吗?
lose大神,帮我看看吧,我都研究你这个自动化框架好几天了,就剩这个抓日志没搞定了,万分感谢啊!!!!!!!!!!!!!!!!!!!!

C6ea3f

顶!!!!

Ba50b7

楼主棒棒的!

717911

要是能开源出来学习学习就好了😂 😂 期待喔

E6c044

@heyniu 你采用是什么报表,比reportng好看多了

9591
heyniu · #33 · 2017年07月21日 作者
E6c044zhf410218 回复

ExtentReports 文中有提到

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册