如何设置自动化测试断言？

看到这样一个问题：接口自动化测试中，有必要把接口返回的每个字段都进行断言吗？

无论是性能测试还是自动化测试中，要不要设置断言，为什么设置断言，断言的作用是什么，如何设置断言，都是新手容易踩坑犯错的地方。

这篇文章，聊聊我对于断言的理解，以及自动化测试如何断言。

1、什么是断言？

先聊聊我对断言的理解。

设计测试用例的方法相信大家都深谙于心，最基本的要素有场景、操作步骤、输入和输出值，目的是验证测试用例对应的业务场景或功能是否如预期实现。

预期输出值可能有一个也可能有多个，在功能测试场景中，我们可以通过界面返回或渲染的结果，与产品需求描述和 UI 设计进行对比，如果符合需求描述和 UI 设计，则判定该测试用例执行通过。

这里的断言方式，可以理解为人工通过对比来判断测试结果的正确性。

在接口测试场景中，输入不同的请求参数有不同的返回报文，常见的做法是通过抓包或者观察 response body 中的返回值来判断程序返回结果是否否和预期。

这里的断言方式，可以人工检查也可以通过工具或者编写代码设置断言来对返回结果进行判断。

所谓断言，就是一种结果判断的手段，即判断结果是或否的方式。

2、为什么设置断言？

无论是研发岗还是测试岗位，都要对自己的工作结果进行判断。

研发在本地开发完成后需要自测，判断自己编写的代码是否如需求描述一样实现。测试同学需要对研发提交的代码程序进行各种验证，判断程序实现的功能是否符合需求描述和产品要求，以及是否满足流转到下一阶段(验收/发布)的标准。

用比较专业的话来说就是准入准出标准，而断言的作用就是尽可能通过机器(工具/代码)来进行判断，避免人工检查可能带来的遗漏等问题。

以接口测试为例，一个好的断言设计可以带来如下几点好处：

• 验证接口返回数据是否符合预期，判断功能实现是否正确。

• 自动化执行，提高测试效率和准确性，减少人为因素的影响。

• 当结果不符合预期时，可以帮助技术同学快速排查和定位问题。

3、一些设置断言误区

很多新手在刚开始进行接口测试或者自动化测试时，最容易犯的错误就是不设置断言，或断言的对象为 HTTP 状态码。为什么不提倡和不建议大家用 HTTP 状态码来作为断言对象呢？原因有如下几点：

首先，HTTP 请求本身是无状态的，HTTP 状态码只是表达了当前请求的处理情况，与业务正确与否无关。比如出现 404 状态码时，被请求服务本身可能没问题，而是你的请求 URL 地址有误。

其次，HTTP 状态码只代表了当前请求自身的情况。比如 200 状态码，代表请求是通畅的，服务端接收了你的请求并成功返回了响应数据，但不代表业务是正确的(下单失败的 HTTP 状态码也是 200，但业务角度来说是失败的)。

4、如何设置测试断言？

以文章开头的问题为例，从接口设计层面来看，设置断言至少需要验证如下几点：

数据结构验证：验证接口请求返回的数据结构是否与接口定义一致。服务端在收到请求后，会按照事先定义好的数据结构来解析并处理数据。如果输入的数据结构发生变化或者与事先定义的不一致，则会导致服务端抛出异常。

关键数值验证：根据业务场景不同，可以有目的性的验证某些 key-value 的键值对结果是否符合预期，同时辅以查询数据库进行数据落库确认的方式来综合验证。

举例：假设业务场景是创建订单，如果创建成功，则响应报文中除了 HTTP 状态码需要返回 200 之外，还需要设置业务状态码(success status=0)。同理，如果创建失败，则业务状态码 success status=1。

要做到这点，有两个制约因素：1-测试同学对业务的熟悉程度；2-接口设计中需要事先对不同的业务场景结果定义不同的业务状态码。

其他类型验证：如返回数据必填非必填，URL 访问权限校验(授权)等。

还有一些特殊情况，比如响应报文中的数据过多，则建议只对关键业务状态相关的 key-value 进行断言，其他数据则仅进行格式校验即可。