问答 接口自动化测试一般都怎么设计断言呀

baobao1 · 2025年02月23日 · 最后由 ginger 回复于 2025年05月15日 · 8297 次阅读

第一次搞接口自动化,想问一下大家在工作中设计断言思路是怎样的?我现在对于增删改查接口都是验证状态码 +body 的重要字段,这样设计会不会不完善呀?需不需要再去做一下数据库断言?

共收到 12 条回复 时间 点赞

ds 回复是这样的,不过我们都是基础断言

你接口手工测试关注哪些,自动化测试断言就是哪些啊。

比如用最简单的一个新建查询场景:
1、创建一个订单
2、查询订单

用例设计:
1、创建订单
1.1 提取:返回的订单号字段
1.2 提取:创建时填写的订单名称(假如创建订单有一个必填且可以作为唯一标识的字段 order_name)
1.3 断言:成功的状态码(比如 200)
2、根据提取的 order_id 作为查询的入参,去查询
2.1 断言:状态码
2.1 断言:查询结果中包含 order_name

正规点就是 200 加上数据结构

绝大部分场景下验证返回就够了,如果这个场景下的数据库结果很重要那就加上数据库数据验证。
如无必要,勿增实体。

前置步骤省略,基础步骤 200,重点步骤 200+ 条件

香百果 回复

我是看出来了,AI 对测试人的最佳应用就是社区回帖😒

  1. 如果是单一接口就根据接口文档来,正向没什么好说的,逆行的就看必填项不填,字段类型错误,多串字段等等
  2. 如果针对业务的多接串联,就是参数传递问题了,如果你们接口是异步处理就是要注意下响应时间,一般一个 post 接口都会搭配几个 get 来验证,一个增改,一个查这样来搭配

始终没想到测试怎么用 AI 提效,用来写用例跟傻子一样,最多的就是拿来写代码或者给个大概方向细化一下测试代码

感觉提问的是思路, 不是技术, 那就从思路方面给一些参考意见哈, 希望能抛砖引玉 :

一般接口会有独立的 code 响应,
比如成功是 200 / OK / Success 啥的,
失败就是 501(502,500 等) / DATA_CHECK_FAIL / FAILURE 啥的,
所有接口肯定都需要进行基础断言, 比如你们公司的接口, 数据处理成功, code 给你响应一个 OK, 你就每个接口都断言这个 code 为 OK ( PS : 这个并不绝对, 大多数项目会在相应状态码基础上, 在响应体的 Json 中给出更加详细的 code 区分 )

甚至可以将这个断言直接写入 requests 的封装中, 毕竟每个接口都需要, 这样你最起码能保证每个通过的用例, 内部的接口都调用通过了

然后就是帖子中提到的各种断言方式, 看你接口需要哪一种, 这里就结合业务和实际流程
数据敏感, 下游接口需要使用某数据, 那你就可以考虑详细断言, 毕竟业务相关就需要结合实际项目来考量
可以是从基础到详细, 考虑细化
或者从详细到基础, 考虑简化
最终找到适合自己项目的断言标准

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