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 代码然后在每个请求后面加上自己的断言，就可以轻松回放接口测试了，优点就是第后面的回归测试绝对舒服，和自动化挂钩了，逼格上升，缺点就是每个接口都需要加上断言，工作量也不小啊，

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

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

求助各位大佬