接口测试 接口测试求助

虫仔 · June 18, 2020 · Last by Eden replied at July 17, 2020 · 1495 hits

1、接口需求描述

查询现金奖品记录,通过参数条件组合获取数据库对应的数据记录,接口文档如下:
url: g####e/query####ist
参数:

 {
b**d (Array[string], optional)对应活动id,
cr**n (string, optional): 创建开始时间,yyyy-MM-dd HH:mm:ss,
c**d (string, optional): 创建结束时间,yyyy-MM-dd HH:mm:ss,
pageIndex (integer, optional): 第几页,从1开始,默认为1,
pageSize (integer, optional): 每页行数,默认为10,
s**No (Array[string], optional): 请求流水号,
s***Begin (string, optional): 定时发送开始时间,yyyy-MM-dd HH:mm:ss, ,
s***End (string, optional): 定时发送截止时间,yyyy-MM-dd HH:mm:ss,
}

返回格式

PagedResponseOfListOfCashPrizeLogDTO {
code (integer, optional): 状态码, ,
message (string, optional): 响应消息, ,
pageIndex (integer, optional): 第几页, ,
pageSize (integer, optional): 每页行数, ,
p***d (Array[CashPrizeLogDTO], optional): 结果数据, ,
total (integer, optional): 总记录数,
}CashPrizeLogDTO {
a***nt (number, optional): 总价值, ,
b***d (string, optional): 业务ID, ,
c***Type (integer, optional): 赠金类型, ,
c***d (integer, optional): 业务系统ID ,
createTime (string, optional): 创建时间, ,
c***d (integer, optional): 用户ID, ,
g***d (integer, optional): g***id, ,
id (integer, optional): ID, ,
p***s (integer, optional): 状态, ,
reason (string, optional): 理由, ,
s***o (string, optional): 请求流水号, ,
s***Date (string, optional): 定时时间,
}

2、需求理解

  1. 带有分页功能的接口,对首页,中间页和尾页的测试验证
  2. 参数中pageSize和pageIndex两个带有默认值,验证其正确性
  3. 除了pageSize和pageIndex以外其它参数会按照并集的形式返回(前端会展示多个输入搜索条件)
  4. 除了pageSize和pageIndex以外,其它参数如果不传递,就不校验该参数
  5. 接口返回的code和message为必须返回字段,其他字段可能会不返回

3、测试用例设计

我先按照非常理想的状态设计测试用例

3.1、业务正常测试
在传递合理的参数前提下,接口必须保证业务的正常,即返回正常和理想数据,可以把这部分的用例抽取一部分作为冒烟测试用例
例如:在管理系统中我们在首次进入一个模块页面的时候,会不传递参数,直接以默认的分页方式展示全部数据
接口入参只有一个分页参数({"pageIndex":1,"pageSize":10}),或者直接连分页参数也没有({}),校验点,分页逻辑,total结果总数,返回结果数量,和里面字段和数据库字段是否一一对应,并且按照指定格式返回(时间格式和浮点数格式等)

3.2、单一字段校验
根据接口的特性,在不传递其他参数的情况下,可以保证对单个参数的校验(pageSize和pageIndex除外),对每一个参数的输入都进行相关的校验,主要有这几点:正确字段(合理输入),空字段,格式问题,数值长度等,这些校验我个人觉得是必要的,但是这些测试用例应该

3.3、组合逻辑判断
这些用例说白了,就是模拟多条件组合查询,验证返回结果是否和预期是一致的,本质上除了就是验证开发在数据库查询上面的逻辑是否正确。个人理解的最直接的验证方法,根据条件组合,形成传参调用接口。案例接口有6个参数(分页参数先不理她),在每个参数都合理正确的前提下,也就是说测试用例数目应该是:6的全部组合=63,what? 63?单单这个需要63个测试用例?小盆友是不是满脸问号,一个简单的不能再简单的查询接口,还是一个不怎么带有其他业务逻辑的单一数据库查询接口,这么多用例?在实际业务中是这些组合发生可能性是完全会发生的,有没有必要完全校验一遍这些逻辑呢?我个人认为是有必要的,为了不当背锅侠,我忍了。

3.3、分页功能和拍序
分页功能,我就不多说了,基本上是大多数查询列表这类接口必备的,分页功能测测试无非就是首页,默认页,中间页,尾页和溢出页(最后页面+n,n!=0)对这些页面验证是否返回正确的页面数据。排序的话,当前这个没有排序要求

3.4、 总结
在理想状态下按照上述规划设计测试用例,去掉几个模块的重复用例,这个简单接口测试用例数量应该有100+,不慌,我们慢慢来。

4、测试执行规划对比

4.1、手动接口测试方案1
采用工具 postman 执行测试用例,按照3分钟执行完一个的平均速度,理想状态下 8*60/3 = 160 一天工作下来,可以完成160个测试用例(摸鱼时间自己在扣除哈,毕竟每个人摸鱼时间不一样),这还只是冒烟之后的第一轮测试,内心毫无波澜。毕竟开发修改完代码,在理想状态下我们还需要继续跑跑一遍用例。

4.2、手工执行+录制回放
采用工具post+fiddler+jmeter,很多人都会说,你一个接口测试,怎么用上了fiddler?fiddler的主要作用就是抓包,记录测试用例的执行(有了这些记录,证明我没有偷懒,要不然一个简单接口测试测试一天,领导要找你谈心的),fiddler的作用当然不止这些,导出jmeter代码然后在每个请求后面加上自己的断言,就可以轻松回放接口测试了,优点就是第后面的回归测试绝对舒服,和自动化挂钩了,逼格上升,缺点就是每个接口都需要加上断言,工作量也不小啊,

上面两个方案我都有过实践经验,我的第一份工作是在一家小型的创业公司实习,公司从事的是虚拟云桌面系统的二次开发和对虚拟云系统的体系完成(运营系统和运维系统开发),在我工作过程中最主要的问题就是时间问题,公司当时的政策是先完成所有功能模块后迭代细化问题,快速的版本迭代和线上问题,让测试小组应接不暇,完全没有时间编写方案二的断言,渐渐加入深度加班大军,无限恶性循环。

有没有好用一点的接口异常自动化测试技术可以推荐?

求助各位大佬

共收到 8 条回复 时间 点赞

没细看,能不能通俗说下你的问题

虫仔 #3 · July 07, 2020 作者

我去看看

虫仔 #4 · July 07, 2020 作者
married577 回复

就是,在没有很充足时间的情况下,没法做接口的异常测试(参数字段空缺,类型不对),只能注重业务,就是看下有没有好一点的接口异常自动生成测试代码的工具或者技术

虫仔 #5 · July 07, 2020 作者

我去看了,还不能满足我的需求,但是已经有点内味了
比如参数异常之类的

1、感觉楼主是类似安全爆破的思维,把可能的组合和场景都列出逐一执行。顺着这个思维可以参考 @测试小书童 的文章,了解下 all pairs 的组合思想,在能找到尽可能多的问题前提下减少组合数量
2、但也建议楼主可以从另一个角度来看。一个是这个接口的100+用例,成本不低,但执行后是否有发现有价值的问题?另一个是,有些校验会不会其实代码里已经用很简单的方式写了,或者其实风险不大(比如起始结束时间,是否直接透传给了 model 层拼接形成查询语句)?

个人经验:
1、现在框架的封装性很强的,开发一个注解就能设定默认值、最基础的校验规则,为了这个做接口测试的单一字段校验(空值、类型不一致、长度不符合等),性价比不高,更建议通过 review 确认。可以了解下 swagger 注解和 JSR303 ,看楼主给的接口文档应该就是 swagger-ui 生成的。
2、分页如果用了合适的框架和正确的用法,基本不会有低级错误存在的可能性(如溢出页会报错)。同样可以通过 review 确认。
3、参数组合在查询类接口,最终其实还是组合成了 sql 进行查询。所以确认组合 sql 的部分逻辑有没有问题(比如用 AND 还是用 OR ),基本风险就控制住了。也是 review 可以确认或者去掉那些风险不高的组合的。

虫仔 #7 · July 08, 2020 作者
陈恒捷 回复

看来想要做好测试,最终的道路还是好好学习开发,感谢,我回去好好学学java

用mybatis-plus做分页查询,返回的接口规范,自己写一个封装的返回类。入参可用dto接收,继承一个基类page,page类中存有成员变量pageIndex和pageSize

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up