接口业务测试 — Java 版

优雅先森。 测试交流1 81字数 1963阅读模式

前言

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

差异性

区别于Http 接口测试框架 -- 回归验证文章源自玩技e族-https://www.playezu.com/184592.html

  • 不只是回归验证
  • 更详尽的用例覆盖度
  • 属于单测范畴,能重复执行
    • Http 接口测试框架的重复执行是不太理想的(传参固定,没有清理数据操作)
    • 举例:第一次拉黑某用户是可以拉黑成功的,再次执行拉黑某用户就失败了,因为已经被拉黑过
    • 本版本的设计初衷是解耦的
    • 举例:拉黑过某用户,断言后,会清理数据,就是会取消拉黑,下次执行就能拉黑成功
  • 更优秀的配置管理

技术层

  • IDE:IntelliJ IDEA文章源自玩技e族-https://www.playezu.com/184592.html

  • 编译:maven文章源自玩技e族-https://www.playezu.com/184592.html

  • 请求:rxjava + retrofit文章源自玩技e族-https://www.playezu.com/184592.html

  • 数据库:SQL Server(与后端同步)文章源自玩技e族-https://www.playezu.com/184592.html

  • 断言:TestNG + 自定义文章源自玩技e族-https://www.playezu.com/184592.html

  • 执行:TestNG 文章源自玩技e族-https://www.playezu.com/184592.html

  • 报告:ExtentReports文章源自玩技e族-https://www.playezu.com/184592.html

项目结构

文章源自玩技e族-https://www.playezu.com/184592.html

请求设计文章源自玩技e族-https://www.playezu.com/184592.html

接口层设计

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 层还未实现

  • 用例的设计需要取经

取经

  • 对于接口用例的设计
    • 数据驱动(一个接口相同的传参,不同的测试数据,但是返回的结果结构不一定是一样的,不太好验证?)
    • 精确设计(能自定义各种断言,但是需要设计众多用例?传参一样,但是数据不一样,返回结构有差异,除非断言不验证那么细?)
  • 数据的准备方式
    • 测试录入(解耦,需要操作数据库,但是线上监控怎么玩?)
    • 业务依赖(一个接口的失败,可能影响其他接口的测试结果)
  • 最重要的还是接口用例的设计
  • 最重要的还是接口用例的设计
  • 最重要的还是接口用例的设计
澳门软件功能测试
 
  • 版权提示:本站仅供存储任何法律责任由作者承担▷诈骗举报◁▷新闻不符◁▷我要投稿◁
    风险通知:非原创文章均为网络投稿真实性无法判断,侵权联系2523030730
    免责声明:内容来自用户上传发布或新闻客户端自媒体,切勿!切勿!切勿!添加联系方式以免受骗。
  • 原创转载:https://www.playezu.com/184592.html
    转载说明: 点我前往阅读>>>
    • 官先生
      官先生 9

      好帖子必须顶一个开源吗?正如差异性说的,取经处 考虑过于复杂,是不是违背了初衷哈哈。。。懒人推动世界,加油,小伙,我们都看好你!!!! 求 GitHub 地址楼主开源吗,还有就是为什么不采用 reportng 报表形式呢接口加密,场景设计,关联这些地方怎么处理的?接口加密

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

      场景设计
      上面我也说了我的思路,所以这个就是我想得到的答案
      关联
      初衷是解耦的,所以没有任何关联
      任何接口都可以单独运行,不依赖其他接口因为那个颜值不够,就这么简单暂时还发不了暂时还发不了哦你有什么好的建议吗赶紧下班回家,老板都给你放假了懒成一头猪了恩,我最近也在弄这块,场景设计我基于 PICT 二次开发,加密规则封装一个公用类感觉搞复杂了….那块复杂了,我参考参考请问下关于重复执行请问例子中 “取消拉黑” 是通过另一个取消拉黑的接口实现还是其他比如清理数据库实现的;
      有时候会发现一些接口流程很复杂,干净的清理数据库几乎不可能,有些又没有反向接口(其实下次运行也依赖了上次的结果了),在想如果有独立的测试环境如果能实现每次自动化前能回退到测试前可能会更好。reset Assured 感觉能省你不少事情说实话看完,并没有感受到亮点在哪,可能是每个公司业务不太一样,感觉没有说清楚怎样能让使用者能更高效的编写接口自动化用例,说白了不知道用你这样做跟用普通的工具框架优势在哪~
      爬接口 文档生成测试用例?

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

      另外我感觉应该是把复杂的东西简单化 而不是简单的东西上手难!非线上环境,应该可以通过操作数据库来实现
      线上环境,不管就好了吧,我目前还不知道怎么玩能麻烦举例一下吗亮点这东西不纠结了,可能我没表达清楚,可能因为没源码的缘故,初衷就是解耦。
      另外用例的编写是这样的,个人认为够简单了
      楼主,我在 Appium 开源框架 appium+python (二) 支持多设备并行 + 性能监控 +webserver 监控 crash 日志 这篇帖子里看到了你写的监控闪退日子的 jar 包源码,但是下载源码后,发现部分模块里没写代码啊。比如
      跟你帖子上贴出来的这个模块一比,发现主要功能的代码都没有啊,能不能重新更新下啊

      另外你说
      想问下这个 libs 是 appium+python 自动化工程下的 libs 吗?能不能截图说明下,我只看到 Lib 文件夹crashhandler 目录下,你把整个项目下载下来就知道了我是想问,下载你的源码并更改 host、port 后打包成 jar 文件,那么打包后的这个 jar 文件要怎么利用到 appium+python 实现多设备并行的框架里才能捕获闪退日志,该放到哪里用;
      我是初学。看了几天了,把你写的 appium+python 实现多设备并行的代码理解的差不多了,就是这个抓取日志搞不懂。

      求 lose 大神详细指导下,谢谢又认真看了你在那篇帖子里的各种回复,总结了一下,我现在是这样理解的,你看对不对;
      把 CrashHandler 打包成 jar,然后把这个 jar 引用到需要测试的 apk 源码的 libs 文件下。再去测试这个包含了 CrashHandler.jar 的 app;如果 app 闪退就会发送日志到自动化框架的 web_server;然后自动化框架才能拿到日志对日志进行处理是吗?
      lose 大神,帮我看看吧,我都研究你这个自动化框架好几天了,就剩这个抓日志没搞定了,万分感谢啊!!!!!!!!!!!!!!!!!!!!顶!!!!楼主棒棒的!要是能开源出来学习学习就好了 期待喔@heyniu 你采用是什么报表,比 reportng 好看多了ExtentReports 文中有提到偷懒过程 1 和 2 实在是太适合我了,最近也是用 java 搞接口测试,也是遇到需要有对应接口返回结构的实体类,写一两个实体时还好,写多了简直很难走下去,而且接口返回的 json 结构又很复杂,期望楼主能单独挑 1 和 2 出来详细再介绍一遍~
      仅楼主可见大佬我想请问下我看你这是 java 项目,但是里面的一些功能还用到 python,我想请问下大佬是怎么将 python 代码放到 java 项目里运行的?

    匿名

    发表评论

    匿名网友
    确定