前段时间看到一片文章《接口测试断言》，里面提到了接口测试中断言的作用和写断言的要点。这篇文章会总结一下我在做接口测试的时候是如何写断言的。
为什么要做接口断言
首先先说一说众所周知的一个问题，为什么要做断言。
假设我们查询我们银行余额的时候发出了一个请求，请求响应的HTTP状态码是200，但是响应体里面返回的是咱们信用卡和贷款的钱。如果没有断言，这个接口用例会通过吗？这个接口实际上通过了吗？
事实上这个接口测试并没有通过，但是在执行的时候这个case并不会报错，这是缺乏合适的接口断言导致的。合适的断言则可以保障接口测试质量。
所有接口测试都需要断言吗
首先我们需要讨论一下，在什么时候做接口测试的时候是需要做断言的。
我们在工作的时候可能会遇到这种情况：“咱们组只提供后端接口，你测一下接口就行”，“前端还没写好，你先测后端接口吧”。在这种情况下我们需要对接口做断言吗？基本上是不需要的，毕竟这种情况下每一个请求我们都会用肉眼去查看，有没有报错、响应是否符合预期我们基本上都能看出来。
事实上，接口测试的断言在手动测试的时候基本上是用不到的，只有在自动化的情况下才会用断言来验证接口响应是否符合预期，例如测试环境的CI和线上的巡检（起码在我的工作中是这样的）。
断言的原则
等值校验
对于稳定不变的字段我们需要做等值校验
举个例子，我们在某社交平台查看一个“胡X进”用户的主页，调用了/ajax/profile/info这个接口，根据我的观察，data.user.id这个字段是这个用户的uid，这个是必定不会改变的，所以我们在对这个接口做断言的时候，这个字段可以做等值校验。
有规律的校验
对于有一定规律的字段我们会根据字段的类型做校验，下面是几个比较常见的例子
数字大小校验
依然以/ajax/profile/info这个接口举例，data.user.followers_count这个字段是用户粉丝的数量，必然是数字类型的返回，所以我们在对这个字段做断言的时候可以判断这个值是否大于0或者是否大于等于0。
内容包含校验
这次我们那不用请求胡X进用户信息的接口做例子了，我们使用/ajax/side/search接口来搜索“胡X进”有关的内容，这个接口返回了一系列和我们输入有关的内容，我们可以使用里面包含的内容是否含有胡X进来做断言，也可以选定某些字段，针对这些字段里是否包含胡X进来做断言。
数组长度校验
这次我们真的不用和胡X进有关的接口了，/ajax/statuses/hot_band这个接口是返回热搜榜单的，其中data.band_list这个字段返回的是热搜榜单列表，返回的形式是数组，那么我们可以对这个字段的数组长度做断言，判断这个数组长度是否为50（通常情况下热搜榜单有50条）。
枚举值校验
例如/ajax/statuses/hot_band接口相应中的icon_desc字段，里面的内容都是有枚举值的，可以定义一个数组，对这个字段是否在数组里面进行断言。
字段为空校验
/ajax/statuses/hot_band这个接口返回的数组我们可以判断长度，但是里面的内容没有规律，我们该怎么判断数组里面的字段是否正确呢。暂时也没有别的办法，只能对里面的内容做非空的断言，确认里面的内容是否为空字符串，或者是否为空。
空字符串指的是返回了这个字段，字段内容为空；空指的是接口并没有返回这个字段。
接口中的所有字段都需要做断言吗
这个问题比较看团队的要求，但是大部分情况下来讲，前端需要展示的字段一般都是需要做断言的。
还是以某社交平台的/ajax/statuses/hot_band为例。icon_desc或者small_icon_desc、num、word或者word_scheme，这些字段是展示出来的，所以这几个字段我们是一定要做断言的，除此之外，数组的长度也需要做断言。其他的字段相对来说做断言的意义则没那么高。
不同情况下的特殊断言
需要注意的是，在线上跑接口和测试环境不一样。在做接口自动化的时候，在线上只能运行查的接口，而测试环境则可以运行增删改查的接口。
与查接口不同的是，增删改三种类型的接口会有异步接口的可能性，在这种情况下，只对单接口做断言并不能验证接口的准确性。需要设计更完善的接口测试方案来验证接口的准确性。
