接口测试 接口自动化测试框架

49875183 · 2015年11月03日 · 最后由 tester1.0 回复于 2022年10月20日 · 15418 次阅读

经过了一年多的接口测试工作,旧的框架也做了一些新的调整,删除了很多冗余的功能,只保留了最基本的接口结构验证、接口回归测试、线上定时巡检功能。

框架的演进

  1. 界面 UI 做了优化,整个框架的画风突然不一样了(人靠衣装马靠鞍 实话)

  2. 加入了虚拟 DNS 切换技术 https://testerhome.com/topics/7061

    <dependency>
        <groupId>io.leopard</groupId>
        <artifactId>javahost</artifactId>
        <version>0.3-SNAPSHOT</version>
    </dependency>
    

    可以动态配置 host 信息,对接口测试环境进行灵活切换
    Dns dns = new DnsImpl();
    dns.update(host,ip);

  3. 更换了 http 请求调用层,改为 rest-assure https://testerhome.com/rest-assured
    这块怎么说呢,因为 rest-assured 也是封装的 HttpClient,如果只是调用入口,优势就不那么明显了,但如果要对各节点进行验证那么 rest-assured 的优势还是非常明显的。
    但我们平台主要验证结构,jsonpath 验证对于空结点处理存在一些问题,还是沿用了旧的 JSonArray 包进行处理。

  4. 框架抛弃了数据、业务逻辑的验证
    我们这边接口测试周期非常短,为了在有限的时间内完成测试任务,测试同学与服务端并行开发测试脚本,使用灰盒测试可以更加快速完成结构、数据、逻辑验证。(灰盒测试前期试行过程中发现此方法更适用于现有工作,所以框架抛弃了数据、业务逻辑的验证)

  5. 为业务测试提供一些测试小工具

个人对自动化框架的看法

  1. 能够做好、落实一点或几点,就是成功的
  2. 能够为测试团队带来技术创新、测试质量或效率提高,就是成功的
  3. 一定要基于公司内部现状搞自动化
  4. 团队成员要达到统一认可、统一目标,一个人使劲一定比不过一群人使劲。
  5. 看到机会一定要抓住,再慢慢落实向前推进,执行过程中如不可行,一定要及时换路子......

公司看重的是结果,过程不重要。。。。。但是对于团队成员来说过程是重要的,经过一年多的摸爬滚打,我们团队也已经从最初的功能测试、自动化测试到现在的灰盒测试,白盒测试,慢慢转变成了一个从技术角度推进质量的测试开发团队。

不过话又说回来,有一个支持你的领导才是最重要的,起步最难,尤其是初期,建议先把团队的头拉到统一战线,后续工作才好进行!!!😁

-----------------------------------旧版-----------------------------------

前言

经过了一年的演进,旧的框架也做了一些新的调整,删除了很多冗余的功能,只保留了最基本的接口回归测试、线上定时巡检功能

加入了虚拟 DNS 切换技术 https://testerhome.com/topics/7061

io.leopard
javahost
0.3-SNAPSHOT

可以方例的配置 host 信息,对接口测试环境进行灵活切换
Dns dns = new DnsImpl();
dns.update(host,ip);

更换了 http 调用层https://testerhome.com/rest-assured

目前在做接口测试方面的工作,结合部门现状,初步整理及搭建了 api 的自动化测试框架,现在把我的思路、框架结构和大家分享出来,一方面希望可以为大家提供一些参考,另一方面也希望大家多提意见,以便测试框架的改进~~

主要目的:

1, 各版本用例管理
2, 结构验证、节点数据正确性校验
3, 简单业务逻辑覆盖
4, 各版本回归性测试
5, 线上环境监控及预警
6, 帮助开发、测试快速的执行接口测试,定位问题

大体构建流程:

一、.接口所涉及的信息都以数据结构形式进行存储。

1,对接口、接口的输入、输出参数进行数据存储(POST、GET)

考虑到接口返回值一般都较庞大、逻辑关系较复杂,如果单靠人工进行采集的话工作量非常巨大,为了缓解压力提供了通过json串解析输出结构的功能。

二、测试用例与接口进行关联,(支持自动、手工 case;正常、异常状态校验)

将收集的输入、输出数据以树型结构展现,通过简单的勾选来完成测试用例的输入参数及预期输出结构进行关联生成测试用例。

除了支持对JSON结构的校验,同时集成了selenium,实现对返回值为HTML的页面进行规则校验的功能

三、测试用例的输入参数可配置,也支持与上行接口的输出参数进行关联。

可以配置上行接口,取得相应节点对应值,自动赋予当前用例接口参数。

比如有些接口需要在登陆或其他的情况下去操作,那么就可以配置上行接口,模拟登陆,然后取得登陆key,用key做为参数去执行用例。
也支持选取规则配置中预先定义好的规则参数

四、接口多种模式执行方式。

提供多样的执行入口

将接口各用例的执行情况(接口耗时 、成功与否、失败原因、异常节点等)信息,记入日志管理模块,同时为测试人员提供测试结果查询页面,对测试结果做大体的分析,尽可能的帮助测试人员去定位接口中存在的问题。

对于频繁变动的接口,影响范围又比较模糊,完全可以以大版本进行自动化回归测试,排查影响范围,以减少人工遗漏。

五、支持各类验证规则配置(集合、长度、类型、格式等)

除了对输出结果进行简单的规则验证外,也支持输入参数集合绑定,可以对集合内所有项进行循环调用、循环验证排查。

六、日常巡检、线上预警功能

当接口打上巡检标识后,系统就会每天定时自动排查接口;同时协助线上环境监控及预警,自动生成预警邮件抄送相关负责人。


1,所有测试人员都可以通过WEB页面对接口进行录入、测试、生成测试报告。
2,在HOST配置中加入测试、开发、生产的IP地址后,系统就可以根据人员自动执行不同环境下的测试任务。
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 40 条回复 时间 点赞

1,2,3,4,5,6,7 可以用 markdown 来写

guzhang

又是干货。果断收藏

—— 来自 TesterHome 官方 安卓客户端

匿名 #4 · 2015年11月04日

必须顶,期待学习源码~!

有源码更好啦

感觉实现起来好难

看了下,工程量很大啊,web 界面是开发做的,还是测试人员负责的。

开源不?

#7 楼 @zsx10110 前台就是用 jquery 的一些简单 UI,都是测试自己做的

nice...正在做 web 系统录接口,刚把框架搭好

学习了...

问下 接口的返回的内容是如何校验的?是需要校验所有的值呢还是说只是校验一些关键的内容。另外能够详细说下规则配置那部分吗?

#12 楼 @zsx10110 这个你有 QQ 没,咱们 QQ 上侃~

#13 楼 @xushizhao 411249087 thanks

#13 楼 @xushizhao 最近也在做接口测试,有几点想咨询下:

  1. 实际项目中大部分接口返回值结构是比较固定的(如均有 status 字段)。目前接口测试的目的之一就是保证 http 200 时返回的数据结构符合要求。目前有没有什么好的方式能实现这个通用结构的自动断言(在用例层,不在框架执行层,如 request 方法)?
  2. 对于上行接口,若大部分用例均对某个接口(如登录)有依赖关系,这个框架有提供这种全局性的接口依赖关系吗?
  3. 这个框架实际开发工作量大概有多大(大概多少人时)?

#15 楼 @chenhengjie123
你说的通用结构的自动断言是啥意思?我表示没有太理解

#16 楼 @monkey 举个例子吧。接口协议规定所有接口返回数据(json)都必须有一个这样的字段:

{
   ...
   "status": {
        "code": <statusCode>,
        "message": <statusMessage>
    }
}

因此所有接口的返回里都应该有这样的字段,所以我设想的最佳实现应该是在全局设置中能指定这样一个 assertion ,然后各个接口自己的 assertion 只需要校验自己接口对应的值就好了,不用再关心这个 status 字段是否存在,同时也避免了大量的 copy paste。

#17 楼 @chenhengjie123 额。。soga。。。默认验证的话,为啥不放在 setup 里面。。。可以不用写多个啊。。=。=

#15 楼 @chenhengjie123
1,我们也有通用的 returncode、messge、result 结构体,对这部分做了统一处理,当 returncode 码正常的情况下,会去验证 result-json 结构,否则的话就直接返回对应的 messagecode 了,结构解构目前也没有想到太好的方法,做了一个递归的通过方法。 当 returncode 码正确,就取 result 下的所有结构与预期结构进行比对验证。
2,对于上行接口这部分,除了提供自选外,也会把这种依赖集成在规则配置中,做成一个全局的变量参数,供选取。不过为了方便各种情况建议多入口模式。
3,主开发算一个人吧,零零散散整了一个月的样子,现在进入优化调整阶段;还有一同事也会帮忙做一些零散性的工作。

20楼 已删除

#18 楼 @monkey 额, assertion 为啥放在 setup 里。。。
现在找到方法了,assertion 默认是自动应用到同级及下级的所有 http request 里的(貌似是每个 sampler 有个返回值,然后 assertion 会自动应用到这些 sampler 的返回值里),所以对于重复的 assertion 没必要每个 request 里面都加一遍,在同一级放一个 assertion 就行了。

我一开始的思维是有没有和 http request default 类似的 sampler 控制这个,方向想错了。

#19 楼 @xushizhao 1 个月,速度好快~感谢分享~

封装 xml 数据格式了不

#23 楼 @naonao0311 我们业务全是 json 的,所以只封装了 json

这个监控规则是怎么制定的?

#24 楼 @xushizhao 巡检是通过 Jenkins 还是直接后台执行的 crontab?好奇好奇哈哈

#25 楼 @turinblueice 是指接口的定时巡检吧?

#27 楼 @xushizhao 是滴,UI 层的自动化测试你们怎么实现,用了 robotium 还是 appium?

#28 楼 @naonao0311 巡检是做了一个定时任务,每隔几小时针对自动化平台中采集的所有接口进行线上环境验证,同时记录接口的访问时长和访问结果,针对 出现异常的接口,获取所有的文件头信息,服务器的 IP 地址,报错信息供开发查找问题
UI 我们这边是用 appium 去实现的

#29 楼 @xushizhao 很棒,有时间交流下子

#27 楼 @xushizhao 对,同时断言条件怎么添加呢?

#29 楼 @xushizhao appium 写 ui?能简单说说怎么写的不,用到什么库,有参考不?多谢哈

多谢 LZ 分享,有几个问题: 框架内部执行逻辑是怎么样的,配置好多个接口后,是串行执行的还是并行执行的?如果是逐个接口串行执行效率会不会太差,如果是并行执行的,具体如何实现的呢?

陈恒捷 [该话题已被删除] 中提及了此贴 08月21日 01:50

这里面没有 selenium 的事吧

有部署的 war 包或者源码吗

陈恒捷 接口测试的一些感悟 中提及了此贴 12月13日 10:29

老徐不是早做出来了么

这几天在学习接口测试,越学越发现自己菜

这个怎么用呢?

saii 回复

接口校验内容使用 rest-assured 很好校验的

不错【哦!】很厉害 干活~~~~

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